Technical Debt vs. Incomplete Work

[aaronjensen]

https://github.com/aaronjensen/software-development/blob/master/technical-debt-vs-incomplete-work.md

[sbellware]

https://github.com/aaronjensen/software-development/blob/master/technical-debt-vs-incomplete-work.md?plain=1#L28

Also, we refer to it as plain old "mistakes". And we don't let ourselves escape from the gravity of using the word "mistake". We have a blame-but-not-shame culture.

[aaronjensen]

Agreed, though I'm not sure about working that in to this particular article. It may cloud the message.

[sbellware]

once your team leaves the context of the current work item, it gets significantly more expensive to re-enter it

Great way to phrase this. Quote-worthy.

[doughtnerd]

I believe there is only one real answer to incomplete work: finish the work. This is often easier said than done. There are usually pressures from the business to produce more business value. It is often easier to ignore incomplete work and build on top of it in the short term. However, the short term is just the short term. Unless your business has little money left and must produce value to get more, or it has unlimited money in order to scale a development team exponentially, the medium and long term have to be considered. Otherwise development risks reaching the seemingly inevitable slowdown that almost all teams encounter.

I agree, it is often easier said than done to "properly" complete the work. What I've seen the most is exactly what you described - teams get pressured to ship features as fast as possible. Often, development teams are measured by the number of tickets and/or features (notice I am specifically saying "ticket/feature", not "value") they deliver from the roadmap. When delivery falls behind, it could mean jobs are on the line. Ultimately this causes teams to prioritize quantity over quality and over time poor design, architecture, and instability creep into the system. If the relationship between dev/business is lacking, even if teams document the incomplete work, they often are unable to get the work prioritized until the "debt" reaches a critical mass and results in frequent outages and failure to deliver.
Failing to deliver breaks trust with the business further and exacerbates the issue.

I'd like to believe that working with product to define smaller units of work (batch sizes), determining the actual value delivered with each batch (rather than believing value is only realized with the complete delivery of a large batch), and pushing engineers to maintain their principles and try to communicate issues with the business will eventually alleviate the issues but with old habits being hard to break, I've had trouble getting buy-in with this in the past (with most just thinking I'm nuts).

I'd love to get your feedback on better ways to approach a situation like this, whether that be ways to communicate, any iterative approach to repairing the situation, etc.

In software and in many other things in life, things are either getting better or they are getting worse. Very few things stand still. If your team is leaving behind incomplete work, they are leaving behind hazards and future setbacks. They are choosing short-term gain for long-term pain. Things will get worse.

There's an interview titled "You Call it Tech Debt, I Call it Malpractice" with Kris Brandow on The Changelog podcast that I quite enjoy. Kris posits that "incomplete work", cut corners, lack of documentation, improper design, and poor testing aren't tech debt but engineering malpractice. He also argues that this more "extreme" language is helpful because of how misused the "tech debt" term is. This is a bit like your preference for calling it "incomplete work" but places more emphasis on the seriousness of allowing poor engineering practices to exist at all.

[aaronjensen]

I'd love to get your feedback on better ways to approach a situation like this, whether that be ways to communicate, any iterative approach to repairing the situation, etc.

Honestly, this is a challenge. It's taken me years with my current project, with steady headway as it went. The tactics I used weren't challenging to implement, but it requires significant resolve and patience. Because we track our incomplete work, we can point to the overall quantity of it. When we run into incomplete work that slows down our value-adding work, I can speak to that. I can say roughly how long the team spent dealing with it. I can explain that it took longer to deal with it now than it would have when we first encountered it. Over time, I can demonstrate that everything takes longer when there is incomplete work in the way, and when we expedite work again, we create more incomplete work that will slow the next thing down further.

I expressed incomplete work as a multiplier on how long things take to release and expediting as increasing that multiplier. We aren't free of expediting yet, the business has its needs (or its perceived needs), but we are making headway.

It can also sometimes help to try and quantify the cost of delay. I.e., why do we need to expedite? Sometimes there's not a good reason and if the stakeholder can recognize this, more time can be unlocked. I'm required to push back, but also I'm required to believe my stakeholders if they are adamant.

"You Call it Tech Debt, I Call it Malpractice"

Thanks, I'll check it out. Sometimes the alarmist approach works, sometimes it doesn't. It depends on your audience. If you cry wolf too many times, folks don't believe you. We do use the term negligence, but this is typically in reference to developers choosing to make known mistakes for some personal gain reason. I've never referred to incomplete work as malpractice, as sometimes (at least from the business's perspective) it is necessary.