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:

1. 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.
2. 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.
3. 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.
4. 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!

Anyway, this is my first post about methodology (and I hope not the last one). I will here consider the importance of responsibility among developers, and how they like to handle their work till its full completion. My idea could be summarized as: competent developers love to hold full responsibility for their work (until completion).

This idea was reinsured after a little chat with some dev geek I know. The key point for good developers is somewhat linked to the acknowledgement of their work. Indeed good developers are valuable, and it is worth saying out loud (I should probably go a little deeper in a next post). And one of the basic needs of such craftsmen relies on the acknowledgment of their work. But how could you feel happy to be consulted as some expert in a specific field if, over the end, the “evil” manager or CEO ruled you out.

This may sound caricatured but there are many ways, the good fellow would feel excluded from his expertise field: cost-related decision (money first), someone else put in charge instead of you, client’s inability to understand/capture the value of your advice, project manager convinced he knows it better, company policy about some imperative technical requirement/restriction, … and even sometimes your advice may simply be trashed away because of your youth and pretended inexperienced or simply forgotten under specification bible from some external self-proclaimed guru.

So what’s the real problem: this hurts the poor developer’s feelings ! Oh yeah I know he is no Cosette, moreover he is some interchangeable piece of low cost coder. Make no mistake, the guy is a robust geek so he is used to this behaviour. Anyway, I really believe that this will finally appears in bad moon resulting in less valuable experience, lower productivity, unworthy work, … and resignation. And you don’t want to loose your technical mindpower, would you?

So, let’s say you want to keep technical experts within the walls. How could this responsible way help? Because competent people love to take full responsibility. Why so ? Why competent people are not found of hiding behind some pyramidal bureaucracy delegation? Simply because they learned that by doing things you may exposed to problems or responsibilities, but it also worth it all. By taking responsibility of a task or project, there is also a very gratifying feeling along with the accomplishment. You sense your work is useful and appreciated.

Another key point is linked to the philosophical concept of Free Will (libre arbitre). As human being, we mostly like to have control, or at least feel that way. Free will (versus determinism) gathers the idea, that someway we have some power/control on our own existence. I would advance that a developer’s expertise is an expression of its Free Will in the work environment.

The relation between Freedom and a developer’s advice may sound obscure. But think again: if your decisions about some piece of technology is the expression of your ideas (and thus yourself), people should really take attention to what you conscientiously say before torning it apart by throwing your experience away.

Lastly, if you’re still unsure about full delegation of technical matter to technical people, you may be interested in Adhocracy, which in some sort extend this concept to company organization. In a few words: the one to do should be the one most capable of it. But you’re still in the need to define what you hide under “most capable”, and for now I will let this as it.

As a conclusion, I think that letting competent people doing what they are good at, will lead your company’s projects to better highs and produce a wealthy work environment. A place where everyone implies him/her self so that the global effort lead to better results. The hard part may be to delegate your control area, or at least share it with the adhoc persons. This may sounds easy to write, but if you have been a Java Guru for 8 years, and you move to some management position, would you think it’s easy to let go and offer the decision part of a project to someone else? Maybe not, but as it’s sometimes harsh to endorse responsibilities, you’ll have your load too by restricting your area of expertise to your current role in order to let everyone handle its own parcel of freedom…

And after all, “With great power, come great responsibilities“.  So don’t make it wrong within your company