KludgeHack

Avoid chaos, don’t let bugs take your project away

Generally I really enjoy reading all kinds of books and articles about real life programming, specially when is about the difficulty to create an effective development process. Dreaming in Code, is such book, focused on the problems that make the development process so difficult.

Bug fixing, is probably one of the biggest challenge in every development process.

Often, when doing the boring and painful task of fixing flaws and patching bugged code, I find myself looking  for ways to do this in a more controlled and productive manner. Because, the more effective way you control your time, the more productive you will likely be.

There is no doubt that most programmers are optimistic and assume that each bug can be fixed quickly, in a short estimated slice of time.

Great books like Dreaming in Code shows that, from a practical point-of-view, this estimates are only a myth. If there is something unmeasurable in computing, that would be definitely the time it takes to fix a bug.

Bugs can even take more time to fix, than it took to create the entire software. On the quest to fix a unique bug, a programmer in the worst case scenario, can find himself in a infinite loop, finding more bugs on the quest to fix one. Some bugs that could at a first look appear trivial, can always surprise you. There’s always the need to plan for uncertainty.

With such failed evaluation system, how can programmers create a fast and controlled triage system? How can the development team prioritize bugs? Is there a pre-emptive choice when comes to bug fixing?

If the time a team spends on fixing flaws can be such a big real cost to the Company, how came there isn’t yet a better system?

Although Scott Rosenberg done a terrific job with his book book Dreaming in Code, he doesn’t provide a solution to this problem.

But he compiled a list of software development mistakes to avoid, that I think should be shared:

1. Don’t leap ahead before you look backward.
The software industry isn’t introspective, says Rosenberg. “There isn’t a lot of examination of past mistakes. That’s the classic technique of engineering in the physical world—the examination of past failures.” Before launching a new project, review past errors and determine how to avoid them.

2. Don’t forget to plan for uncertainty.
The biggest mistake software developers make, says Parkinson, is to assume their time estimates are perfect. “People can be distracted by many kinds of unplanned events,” he says. To compensate, Parkinson advises introducing “slack”—contingency time to be consumed when adjustments are needed.

3. Don’t cave to unrealistic expectations.
Too often, software developers overpromise what can realistically be delivered in the allotted timeframe. “Managers tend to get into saying, damn it, I want it yesterday,” says Rosenberg. It’s a dangerous game that leads to faulty code.

4. Don’t expect uniform productivity.
It’s unrealistic to expect the same amount of output every day, says Parkinson. “I have seldom seen this happen,” he says. “Better to manage trends, where you can smooth the daily data into a useful indicator of progress, than to panic over daily fluctuations.”

5. Don’t go for the grand slam.
Holding off a launch before the entire project is finished might be a mistake. “If we try to design a system that does everything everyone wants it to, we’ll never have any system,” says Rosenberg. Instead, break projects into small bites. “Any opportunity to do that is to be seized,” he says.

Concluding, I advise that if you appreciate a experienced developer point of view on real life developer challenges, read Scott’s book. He shares his thoughts and experience on this matters, trying to figure why “Software is so hard”. I guess every programmer should know the crazy business they are into.

Quoting Donald Knuth, author of The Art of Computer Programming:

Software is hard.