> Part of the problem is that software is never really "done"
Absolutely. The cognitive dissonance is bad enough that we might be overdue for a change in vocabulary, starting with the word "done". Even hypothetically perfect code needs to get ported to a new architecture, OS, VM, and/or compiler at some point.
I think we, as technical experts, do a terrible job explaining that every piece of code old and new has an ongoing cost. The discussion points should be about which costs are higher and whether trade-offs are worth it. Are the ongoing costs (is the team even aware of what they are?) lower than the cost of change (how do we know it was worth it? can we change our mind if it wasn't?).
While the article brings up many good points about bottlenecks, estimation, and allocation of resources, I find that bad mental models of how software development works costs far more, albeit in subtler ways, than "Heather can do 12 units of work but we only gave her 8 and she blocked a lot on task Alpha instead of moving on to something else".
Continuing that line of thinking, one of my epiphany moments when I first arrived at a dominant player was the acceptance that we would ship with bugs.
The way to stay at the front of the race is to prioritize your bugs and fix the right ones in the time that you have because if you think you'll get them all, you'll never ship. Get the ones that have the highest probability of causing your customers pain and know that you aren't ignoring the ones that are scheduled for your next maintenance release. Debate intelligently if you think something needs to be reclassified as a higher priority and learn to accept that there might be a couple that you don't win so you can get on with covering as much of what remains as possible.
> we, as technical experts, do a terrible job explaining that every piece of code old and new has an ongoing cost.
It's always hard to find good metaphors for programming programming as a craft, but I liken it to a factory or campus.
Even when it is "built" and producing value, there are always issues with maintenance and renovation and replacement.
"Technical debt" isn't just maintenance costs, but the restrictions placed on what you can do next. Ran an electrical line straight across the lawn? Now you have to black-out a building to progress.
Absolutely. The cognitive dissonance is bad enough that we might be overdue for a change in vocabulary, starting with the word "done". Even hypothetically perfect code needs to get ported to a new architecture, OS, VM, and/or compiler at some point.
I think we, as technical experts, do a terrible job explaining that every piece of code old and new has an ongoing cost. The discussion points should be about which costs are higher and whether trade-offs are worth it. Are the ongoing costs (is the team even aware of what they are?) lower than the cost of change (how do we know it was worth it? can we change our mind if it wasn't?).
While the article brings up many good points about bottlenecks, estimation, and allocation of resources, I find that bad mental models of how software development works costs far more, albeit in subtler ways, than "Heather can do 12 units of work but we only gave her 8 and she blocked a lot on task Alpha instead of moving on to something else".
Though your mileage certainly varies.