Tom Breur
25 September 2016
Some writers make a
distinction between “real” technical debt, and sloppiness in coding. I think
that distinction is correct, and insightful. Accruing technical debt is a
business decision, not some “accident” that happens to you because you happened
to be in a hurry, when you cut some corners….
As teams progress
through their adoption of Agile, I have seen their thinking about technical
debt evolve, too. In the early stages, enthusiasm, and placating (trying too
hard to please their Product Owner) can contribute to some relatively innocent,
small scale accumulation of technical debt. As the “rush” of success takes a
hold of them, they may feel confident enough to try that recipe some more. Sloppiness
leads to ever more intricate design flaws, that become increasingly expensive
to fix.
Then, as the team
becomes aware of the risks and consequences, they start out with a phase of
denial: “we can still fix this, maybe in the next Sprint”, etc. But instead of
features taking less effort to
complete, it is beginning to take longer and longer… Automation is (too) low,
and the technical debt is starting to weigh down on productivity.
As the time it takes
to fix bugs keeps growing and growing, and management begins to wonder what is
wrong, the team gets desperate. They practice “the blame game” more often than
their coding skills, and the team spirit crumbles. Not a great place to be.
When your once star team members begin to jump ship, you know the end is near.
Such a sad story…
It doesn’t have to be
that way. But in order to avoid this pernicious dynamic, you really need to
understand what the exponential cost of bad design (“sloppiness”) really means.
How costs will rise as a function of time and accumulation of debt. If you want
to create a different future for your team, the future is now. Or as I like to say, tongue in cheek: “Don’t put off until
tomorrow, what you can put off until the day after tomorrow… ”
No comments:
Post a Comment