It’s an all too common pattern: software gets build as quickly as possible to deliver “what matters the most”: FEATURES. All other concerns are swept aside. It’s understood that by doing so you will build tech debt, but who cares? Users want features, and we release them.
So typically features get cranked out as quickly as possible, and with them a decent number of defects, but as far as the number of defects is less than the number of features, we’re good.
… or are we?
As the graph above shows (courtesy of @realGeneKim), while you are busy cranking out features, two things happen in the background:
- The quality of your product decreases
- Your tech debt and risk increases
So what? Well, with time, your arrows end up looking like this (also courtesy of @realGeneKim) :
So with time you’ll find yourself in a position where you won’t be able to deliver features because your quality will be soo poor, your defects so many, and your technical debt so high, that producing any new value for your customer will require huge effort.
What can you do about it? Prioritize reduction of technical debt and developer productivity above all else.