I was reading an article about a right way to handle the “Debugging process” (as some project manager could call it) : Do It Yourselft!. And I must confess I quite agree with these ideas (quite is to make sure I can switch my beliefs if it turns out google doesn’t help anymore in the process, or some other external factor). By the way, this article may really useful next time I get something asked which I don’t want to reply because it’s too simple, too long, too pathetic, too obvious, … or simply if I don’t know the answer and don’t want the guy to know. So I could seem really smart by pointing out an elegant and simple procedure to follow. (Of course I would never do that, or well maybe… just try me!)
Anyway, I would like to add my 2 cents: the solution of a debugging process (or simpler a bug fix) should be ASAP, which here means As SIMPLE As Possible.
Why simple ? Because every developer does know the world is flat! and so are the bugs. Convinced? Not really huh, me neither ! So I will give you my 3 reasons to think bug fixing should end in a simple explanation:
- If you have a wealthy development environment, you should use some unit testing library. So when writing your test before the code, running them will lead you to discover bug. This early detection is a kind of warranty that bug fixing should be simple or easy, since you don’t have already a bunch of thousand code lines with multiple FIX ME later todo’s. This early detection phase is even better if you apply a Stop The Line principle (cfr Lean Software Development, Bugs are Stop-the-Line Issues and also this book ref1-ref2). This means: fix the bug(s) before coding more. This way you keep your project clean instead of using couple of bug fixing weeks at the project’s end.
- This point is more or less related to the “Fix First then Code“. You probably know how bug fixing can be cumbersome when you have multiple causes. Indeed, when you try to identify the problem and discover that there are a lot of function points causing the disease, you will probably do some cumulative messy patch to achieve the correct behaviour. But the real problem is that you some way let this mess happen. So again, keeping a clean code should avoid fix of cumulative defaults and provide rather quick and direct solution to appearing bugs.
- When reading the article from Sébastien, it remind me the episode 103 of House MD – Occam’s Razor (tv.com, wikpedia, housemd). Why House MD? Because, as a physician, he extensively uses what’s these docs call Differential Diagnosis (or DD) . And the procedure proposed by Sébastien is well a DDD, Differential Diagnosis for Debug. Use symptoms to try to list the possible causes and proceed by elimination until you get the right one. The 3 same steps !
By the way, I also get the notion of Occam’s razor in some Computer Science course. Just as a quick reminder, the idea is very appealing: the simplest solution tends to be the right one. IMHO, I think this DDD is the right approach but I would enphase the idea that the causes and effects inherent to the bug, should be solved by the simplest correction possible. - Oups… here is the 4th hidden extra reason! If a debug is tricky this may due to poor design, bad coding habits, wrong specifications, no documentation or tests, … So let’s stick to the KISS principle (Keep It Simple, Stupid). In definitive, the debug phase should be simple because you should never have some obscure, monolithic, incomprehensible specified, undocumented, untested, 10000+ lines of code to say “Hello World!”. Thus applying simple and well known principle, will probably help you to have easier debug processes.
Last, I will never say you will have no bugs… well because it’s a lie. We are all simple error-prone humans. Nevertheless, following the procedure described in this article and following some of my humble advices here, should help you to acquire good developer’s reflexes.
I should also admit that sometimes there is no simple explanation or solution. Yeah, sometimes you have to work it out for hours to finally get your piece of code working. But that’s life too!
You just forget one thing my friend: sometimes very tricky bugs can appear and make you lose a huge amount of time, not because of crappy design, wrong patterns or messy documentation. But because of both our best friend and worst ennemy: integration. When your don’t only work with your code but integrate code from others, like frameworks and libraries, well, you know how it works: framework A is bug-free, framework B is perfect but both rely on contradictory assumption or default configuration and BOOOM! It’s as if Doctor House had to diagnose brain cancer on Robocop!