Beep! Beep! Beep!…. goes your alarm clock. Yawwwwn! (what the hell). Snooze!
After 15 minutes…
Beep! Beep! Beep!….. (the darned clock). Snooze!
After 15 minutes…
Beep! Beep! Beep!…. (damn it, I am late)!!!
Sounds familiar? Most mornings (especially the ones on Mondays) are like this. I am wondering if this behaviour of being lazy has made its way to other aspects of our life too, particularly, software development.
We are in a mad rush to meet the launch deadline so we decide to skimp on some quality, cut a corner here and there, essentially creating a product held together with gum and baling wire. We agree to attend to those quality issues later, replace those quick-fixes with a better solution in the next release. The product launches and is well received. And in the process we receive some rich feedback on what new features to include. Or maybe the launch isn’t as exciting as we had anticipated and we consider some features to add more teeth to the product. Either way, we are in the mad rush all over again to quickly add the new features to our product. So we decide to postpone replacing those quick-fixes again and in the rush to release soon, we accumulate some more quick-fixes and cut corners. The release happens and thereafter we create another list of features to include in the next release. We also include, rather grudgingly though (as we are in a rush again), some quick-fix replacements that we had promised earlier. But now, while working on this release, we realise it is getting difficult to add new features. The product breaks at unanticipated areas whenever we make a small change. Those quick-fixes have rendered the product unmaintainable. So we are spending more time managing the mess rather than making improvements / changes. In the process of becoming faster, we have actually become slower. In short, we are having challenges repaying our technical debt that we have accumulated and now the interest for the debt is more than the principal. This is what happens if you keep hitting the snooze button on your technical debt.
While it is acceptable to prioritise quality issues and work on the most urgent ones for now (do some quick-fixes for now), it is imperative that those quick-fixes get replaced by more elegant solutions as soon as possible. If you fail to keep a check on the accumulating technical debt, the product soon turns into spaghetti that no one can segregate (or even eat). The old adage “a stitch in time saves nine” emphasises the above points. Looks like our forefathers were wiser than us after all.
So, if you want to have your product grow continuously, you would have to keep the technical debt low.
Don’t snooze, wake up!