Today’s entry describes one way in which development teams can benefit from disorder.

In my previous blog post, I introduced the triad of fragility, robustness, and antifragility. The fragile dislikes chaos, the robust is resistant to chaos, and the antifragile can benefit from chaos. I also mentioned that some amount of disorder (stress, change, volatility, variation, chaos, and the like) can potentially improve systems–software or otherwise–and I think that individuals and organizations can sometimes benefit from adding disorder to their environment. What categories do software and software developers fall under, and how can we make our development systems benefit from stress?

Like an iceberg, the costs of waiting to solve a problem can be quiet and tough to see. Photo credit: Ilya Haykinson.

I classify software as fragile, but software developers as antifragile. When a programmer is hit by a problem, he or she can recover from it, resolve it, and use that knowledge to prevent related problems in the future. A program encounters an unexpected bit and shuts down completely.

Of course, too much chaos can destroy an individual altogether. I am not advocating for complete disorder. Rather, I am noting that individuals can benefit from a some amount of chaos in the environment. However, it may take a certain perspective to realize how unexpected problems can help an a team of developers.

Development teams can become more antifragile by fixing mistakes immediately (if possible). Consider a fragile team of developers. When they encounter the slightest problem, the entire system breaks. A robust team, on the other hand, is not bothered by the issue. They solve it and move on.

An even better reaction, made by an antifragile team, solves the problem quickly and also finds the root cause. This prevents further errors and allows the codebase to remain intuitive and extensible.

However, a developer (myself included) might think that patching a new bug is not a priority. “It will take too much time,” we think, “and we need to implement feature Y by next week.” So why not put off the fix until later?

First of all, It’s easier to recall the mental model of a certain object on the day it was first designed, rather than six months down the road. In addition, a codebase tends to increase in size with time. By fixing bugs at the source, errors are caught before they propagate. Future extensions won’t have to deal with spotty documentation and untested corner cases if those problems are caught at the source. And finally, we won’t have to inform new team members about software “folklore”–things the company does but few know why.

The previous paragraph describes an ideal situation. In the real world, we can’t solve every problem immediately. Sometimes it may be more valuable to press onward with development than to patch an old bug. Nevertheless, the costs of waiting too long can be quiet and invisible. No one notices a thousand careful captains avoiding an iceberg, but everyone knows about the Titanic.

So let’s avoid disasters. Consider the hidden costs of waiting to fix a problem, and see for yourself how you can benefit from disorder.