After this article was posted, Matt Eland wrote a remarkable article with additional information that goes well beyond this one ...
...
For further actions, you may consider blocking this person and/or reporting abuse
I think the real reason technical debt is left unattended is usually to do with the fact that the people running the company and paying the wages don't care about it. That's certainly been my experience in enterprise software development. The dev teams themselves usually have very little say in where their time goes.
"thing" is launched... move onto the next "thing"
Dev Team "Ah but we need to refactor"
Overlords "It's working isn't it... ON TO THE NEXT THING!!"
This is something I think a lot of teams deal with. Why do you think business feels that way and how do you combat it?
I can't answer for Mick, but my thoughts are that business has only seen one way work; they assume that the debt can't be too critical since the code works.
They haven't seen the benefits of a strong CI/CD pipeline and the positive impact of proper testing. With these things in place, there is often time to go back and address the tech debt issues properly.
Addressing it in my experience is often the result a slow cultural shift toward code quality ownership, proper testing and pipelines, as well as a focus on writing clean, readable code. Combating the business has to be gradual ... but it can and needs to occur.
I'll probably write an article on my thoughts around actually paying down technical debt over the next few weeks - as well as some thoughts about communicating that debt to business in a way they can understand and make good decisions as a collective group.
I love these discussions, but I fear that the negative feelings in Mick's post are very common and I wonder what we can do as engineers to better expose, communicate, and solve these problems.
I'd love to see that article.
I agree about the negative feelings being very common ... in addition, if the developer is not strong (personality, not coding), they can get run-over by management. I've been there ...
Let me know when you get the article done and I'll add a link to this article.
Communicating Technical Debt
Matt Eland ・ Oct 2 ・ 10 min read
Added a reference to your article!
Excellent work!
I would add a category of 'maintenence debt'.
Debt that appears as underlying technologies (like programming languages, libraries, infrastructure, etc) go through normal updates aka new version releases. Including deprecations.
This is debt that appears over time & no amount of careful planning can avoid it. And it snowballs if ignored.
I will look into adding that over the next few days. Great points ... can I quote your last two sentences?
Sure!
Bob, this is great. This squares well with a lot of what I've read and have been thinking about. I sat down to lunch to read Managing Software Debt but read your article instead.
Nice one mate !