I guess if you are reading this you will have some understanding of Test Driven Development or TDD. Whether you buy into it or not, the basic concept is to incrementally build up a suite of tests that act as a framework in which to build your code. The test suite acts as an executable specification that determines whether the code fulfils its purpose. It can also be used to ensure that only the code that is needed is written. If code is written that is not causing a failing test to pass or improve the overall quality of the code base, then does this code have value?
I like to think of the test suite acting as pressure that drives a solution forwards in a given direction. A test suite is not the only type of pressure that can be applied to development, there are other types. The one I’d like to focus on here is chaos.
- Complete disorder and confusion
It is not really chaos itself that is the pressure, it is the emotional effects that result from it. Okay, some people thrive in chaos but for the rest of us, it generates worry and concern. Some people switch on the heroics but others become stressed or are unable to act through the fear of doing something wrong. Fear Driven Development is a related concept.
With TDD the developer is motivated to write code that turns the light green. This often (although not always) generates code that is simple, logical and easy to maintain. On the other hand, when people are under pressure due to chaos, the motivation is to remove the pressure at all costs. This leads to short term thinking, designs and good intentions go out of the window and “good enough” and “that will do” become the norms. Unfortunately, the short term thinking creeps out to other stakeholders and suddenly the developers who are hacking at code to alleviate the pressure get the kudos by being rewarded for their heroics.
With TDD people often forget the refactoring bit. In Chaos Driven Development you don’t have the chance to improve things. You are already a hero and you’ll be needed to go into battle fighting the next fire which is even more likely because there is never enough time to fix things properly.
|Test Driven Development||Chaos Driven Development|
|Can simplify the code through Red – Green – Refactor.||Can generate spaghetti code by patching the symptom rather than understanding the root cause.|
|Testing is built in and automated.||“It worked on my machine!”|
|Regression Safety||Praying a fix hasn’t introduced another problem and “that was working last week!”|
|Code Ownership through collaboration||“I’ve got this” and “X is leaving, what do we do now!”|
Chaos Driven Development is unsustainable. It leads to stress and low morale which leads to people leaving. When someone leaves, particularly if they are considered a hero, it is just another fire to put out which adds pressure to a team that might already be at breaking point. The problem is only going to get worst – the fire will start to burn out of control. And when that happens often the only option is to build some fire breaks around it and let it burn out.