I'm a blogger and travel writer and have been writing a series of articles from Nepal. One of the reasons I do this is to encourage other people to...
For further actions, you may consider blocking this person and/or reporting abuse
Great article. I think this is related to conversations we need to have with the businesses we work for about technical debt. The first thing that happens when technical debt goes unaddressed is developers end up working longer hours, under more pressure, which snowballs quickly. (Family, friends, and and health are compromised, weekends skipped, etc.)
Thanks for that Chris
Good point
But it raises a challenge:
How to structure that conversation?
It risks being one of those things we
SHOULD DO...
I think tech people should just explain to business people the consequences of ignoring the tech debt.
From what I've seen, managers and product owners tend to ignore tech debt, because repaying it usually means performing refactoring, and refactoring doesn't bring any new features to the product. So it appears useless to people who are interested in revenue. And if those people come to understand that tech debt will eventually lead to decrease in revenue then it's likely they will do something about it (or so I hope).
It would be great if developers could have a fixed amount of time (and budget) to do tech tasks.
Other problem which I've encountered in some teams is that developers are required to estimate the time for completing a task in hours and after that those estimates are treated as deadlines. Add tech debt and missing knowledge about some parts of the project you're working on to the mix, and say 'hi' to overtimes, because you have to meet deadlines somehow.
I wish it were that simple. But I think the problem is tougher than that.
I think that the most productive way forward is to start from the premise that the business does understand technical debt, but that they don't have enough visibility into how much has been accumulated, and what the likely effects of that debt load are. They need to be kept updated about how the technical debt is slowing development, causing more issues to be found in QA, requiring developers to work extra hours, increasing the frequency of production issues, etc. I'm a believer that open, clear communication really does improve decision-making and relationships within the business.
Unfortunately, I think it's often true that the business does understand technical debt, and it's consequences, and that they've consciously decided that those consequences are acceptable, even if they make the dev team miserable. If that's the case, your best option is to keep an eye out for a happier place to work, and move if/when you can.
I agree. I think the trick lies in finding a way to measure technical debt, either directly (using something like Code Climate, or something else that can track the "spaghettiness" of a codebase) or indirectly (maybe by tracking the drop in team velocity as tech debt accumulates?)
A team I used to work on used to create actual tickets (we used Jira) to track technical debt. If a feature was needed on a given deadline, we'd cut whatever corners we had to, and create a second ticket to remediate the technical debt. That tied the debt to specific features (so it could be canceled if those features were removed), and gave management visibility into the general health of the code, and the impact of aggressive scheduling demanded by the business.