It's Cool to Break Stuff

May 11, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

I am a proud father of two kids – 5-year old girl and 1.5 years old boy. For the most time they are good kids. But with alarming regularity, every couple of months, they turn out into terrifying monsters. For example, the boy would go to sleep at 7:30 pm each day and sleep well till 7am in the morning. Awesome. And then suddenly he would decide to stay awake for the whole nights for extended periods of time, and his poor parents would of course not sleep as well, turning into walking zombies during the day. Curiously, the little guy does not seem to be tired at all, even after his series of sleepless nights. Or my daughter would one day decide that she no longer likes to eat anything – with the exception of ice cream.

My wife and me used to be disoriented and powerless when this happened – until we consulted a child psychology book that described the phenomenon. And what do you know – not only is such a behavior of a child expected and normal – it is essential for the kid's development! Kids have to break the rules regularly, in order to build something new on top of the rubble.

By now, you can probably tell where I am going with this extended tale of my family life: the same rules apply to the software project. Every once in a while – and regularly – break something and re-fix it in a new way. Otherwise, your project, its internal architecture, its priorities, its target audience, its feature set, will petrify and very soon cease to be useful, attractive and desired.

You should explicitly plan for breaking something in your project regularly, so that the impact of the destruction will be minimized. Starting from the micro-level, the rule can say “30% of each iteration goes to refactoring, because as we all know, this code stinks” (yes it does, I am yet to meet a quality software team that would claim otherwise. The teams that refused to admit that their code is no good were without an exception very lousy teams). On a more macro level, during the release planning, it could be specified that twice during the release cycle (say – every two months), the team and stakeholders will reevaluate the ergonomic quality of the UI and rebuild it (from scratch if need be), because it is tough to get it right the first time around. Well, you might not actually have a UI in your product (hello, OS driver developers), but whatever your project domain is, plan to regularly reexamine whether you still like where the project is going and whether you like how the internal design looks like.

How can you tell that it is now time to “launch some grenades into this cesspool of suck”? Your team will know – the right moment is when the developers start to complain that the architecture of the system is too rigid to add new features or when during standups you hear more and more stories of people fighting with some particularly problematic piece. This is when the decision should be made to refactor and redesign.

Be aware that planning the breakage does not make it totally painless – it will still hurt. Agile methods such as regular refactoring, automated testing, CI, help quite a bit, but absolutely do not make the pain go away. After each refactoring and redesigns, the system will be in an unstable, sorry shape. You will have to fix quite a few of bugs and work hard to make it stable again. But the alternative is much much worse – if you fail to refactor your project regularly on a macro and micro level, you will end up painting yourself into the corner, ending up with a product that is not easy to extend or modify any more, with outdated UI, outdated feature set, not attractive to your customers and frustrating to work on for your development team.

Permalink