Woah, Nellie.NET!

From my simple mind to… mine…

When looking for bugs, it’s the little things that get you…

leave a comment »

WOW. After a week of squashing miniscule, obvious bugs (obvious only in hindsight, mind you!), I went home to 2 days of the same thing with one of my side gigs.

Arrrrrrrrrrrrrrrgggh…

Some lessons learned when rooting around for the problem, if the problem is especially problematic…

1. Don’t assume anything. Nothing. All possibilities should be on the table until 100% ruled out. Then have somebody else rule them out. ‘Nuff said on that.

2. Don’t assume the problem is with the “other guy.” Never. Ask the “other guy” to verify his stuff, but never assume. The “other guy” can be another system, another programmer, an infrastructure guy, an outside vendor… whatever.

3. Check your code. Then check it again. Then have somebody else check it. If you’re pairing, switch pairs and get a fresh pair of eyes on the problem.

4. Live by the 20 minute rule. If in 20 minutes you don’t have any insight into your problem, bring somebody else in or fire up Google.

5. Don’t assume any problem is in one specific area. Exceptions can be very limiting in the information they convey and the problem can originate somewhere else before it shows up as the exception showing up in your log. For example, check case sensitivity of parameters (yes, this was one), check other variables being sent across, look at code leading up to the problem, etc.

6. Google is not always your friend. If the exception is misleading to begin with, then sometimes when you search for the problem, you can go down many different incorrect paths before stumbling on the correct one. Be wary of this. Try to do some logical reasoning on whether or not the solution that has come up in the results even applies. Still, if you’re stuck, fire up Google right away.

7. Take a break. If you’ve stared at the screen for long enough, it’s time to take a break. Hit the gym. Get some sleep. Do anything else. Your brain needs a change of pace, so go.

8. Make sure that you have test coverage!!!!!!!!!!!!!

9. On that note, make sure you are testing the correct thing. Just because you have a test in place, doesn’t mean you have everything tested. Of course, if you’re doing proper TDD, this should not be the case… but it happens. Interaction testing via mocking frameworks are very useful.

10. Don’t assume anything. Nothing. I know… already said. I’m saying it again.

*sigh* I could’ve gotten some sleep last night. But it’s time for some Spurs action!

Advertisements

Written by Nelson

April 19, 2008 at 7:25 pm

Posted in Miscellaneous

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: