Being a software developer (but I don’t think that this necessarily only applies to programming), I often find myself troubleshooting/debugging my code. This is especially true now that I’m messing around with JME (formerly J2ME), which presents its only fun set of issues. But anyhow, anytime I’m troubleshooting I find that the first stumbling block to overcome is to acknolwedge that it’s broken. You know what I mean: you keep running through the application hoping that magically the part that keeps failing will suddenly work. In the C++ world this sometimes happens because of bad pointer usage, but in the Java world you can’t go down that path. When you know it’s broken, really know it, step back and look at where exactly the problem might be. Some questions to ask:
- Where is the last place the output/data looks correct?
- What inputs/interactions have taken place since then?
- Are you using “dummy” data that isn’t well thought-out?
- Entering ‘test’ for all of your text inputs is not a good idea, how do you know which is really being assigned where?
Some techniques that I find useful (your mileage may vary):
- Old-school “printf” style logging of important variables
- This is great because you only see the ones you care about and you can put as much or as little as you want at key points. You can even do complex logic (if that will help, such as testing multiple boolean variables or for a particular value).
- Run through a debugger
- I actually haven’t done this in quite a while, when you have a lot going on stepping through is frustrating and you end up missing the point that you wanted or you have *too much* information.
- Again, don’t forget it’s broken! It won’t fix itself. And if it does, be afraid because it will break elsewhere and probably corrupt data down the road.
- Write a unit test (because you know you haven’t already done this) for the specific method(s) you think are failing.
- Warm it up with some “expected” data
- Throw a curve-ball; if it’s expecting a positive number, throw a negative one at it, or a null value. Give it a text string if it’s taking a character string that it expects to contain a number (e.g. “3”). You can also do the equivalent of assert() on all of these (in Java, I throw a RuntimeException or IllegalArgumentException).
- Take a few (code) steps back
- Check the outputs of methods that happen before the one that seems to be failing. There can be a chain reaction of bad inputs/outputs that begin from one small thing.
- Take a few (real) steps back
- Take a breather. Go have a drink. Chat with a co-worker. It’s like getting that “second eye” without having to bother anyone. Seriously, this works.
I firmly believe that the ability to troubleshoot is more important than the ability to write the code for the first time. One one of my regular blogs someone wrote that “As soon as you’ve written a line of code, you’re maintaining it”. It was meant in terms of writing clean and readable code, but it also applies to the ability to actually do what it’s supposed to. Readable code that doesn’t work is pure evil; you almost feel guilty about modifying it even though you absolutely must!
Face it, much of your life as a developer is going to be in fixing your, and other people’s, code. It’s time you got good at it. Think of it as an excuse to truly learn the codebase, you may even find some real gems in that rough: truly poetic code that does exactly what it should.
Reading List (this stuff will make you a better engineer):
- Raymond Chen – Writes about problems (and, more importantly, the thoughts that lead to those problems) and how to fix them in terms of Win32 development. I don’t do Win32, but I read it every day.
- Anything by Steve McConnell, especially Code Complete (now in it’s 2nd Edition). Go buy this right now. If you don’t think it’s amazing, I will personally buy it back from you (but you have to send it me so I can give it to someone else). I have no affiliation with Steve McConnell. Another amazing one is Software Estimation: Demystifying the Black Art. Search for “software estimation” on Google, it’s the second link for a reason.
- Worse Than Failure (formerly “The Daily WTF”) – Highlights less-than-great-and-perhaps-just-a-little-horrendous code snippets (disguised to protect the not-so-innocent). Admit it, you’ve written some of this code.
- Hacknot – I stumbled on this a couple of months ago. Not as regularly updated as others, and I don’t agree with everything he says but he’s passionate about what he believes and backs it up with a lot of thought. Also has a great troubleshooting guide.
- Salvatore Iovene – Infrequent but of great quality, especially his rant about why many programmers suck and how to fix them.
- Joel On Software – No reading list can be complete without him. Both the blog and, especially, the book. He also has 2 more books are software writings (basically he edited the best stuff found from the tech blog sphere, but I believe he links to them on one of his entries). Even if you don’t agree with him, he links to some other amazing articles which has helped me grow my daily reading list.
Have any others, let me know! I’m always looking for other insights and views on the art of software engineering.