I’ve had some success recently explaining tech debt using spreadsheets. In fact, it’s worked well because spreadsheets tend to be living manifestations of tech debt with very little recourse but to rebuild.
How many times have you heard the phrase “I have to go rebuild the model”? Would that be excusable for an engineering team to just go and rebuild something every time we hit an unforeseen circumstance? No? Then it shouldn’t be OK for the Biz Ops folks, either.
Every single time I have used this framing, my engineering team has been given leeway and dedicated time to work on tech debt. Every single time.
What type of company do you work in that you hear “I have to go rebuild the model" from business folks?
I’m on the executive team at a 100-person education company. Also, I was being a bit extreme – they don’t often say “rebuild”, but they do often make reference to the amount of work they must put into their operating model (and it’s true).
Whenever someone asks me why my engineering team is working on technical debt, it’s an exceedingly useful item to draw their thinking back to. “What if you couldn’t rely on the integrity of the cash reporting tab because of some prior hack you’d done to get it ready for a presentation?”
Funny but useless explanation. We need attempts that translate the effects of technical debt to stuff decision-makers understand. I rarely see any posted but this one caught my eye a while back:
Technical debt is exactly what it sounds like. You are buying a holiday to paradise island on the CC and 6 months later you are now paying 20% interest on it monthly.
Alternatively you can save up for 3 months, buy the holiday with cash and congratulate yourself for having the ability to postpone rewards and plan ahead.
I hate the term “technical debt”. While it is perfectly feasable to run a life or business debt-free, you cannot develop software debt-free.
Even some solutions that worked for a while will become antiquated because of unforseen things happening. No one will remember “taking debt” there, and suddenly, it’s there.
That’s like when you discover you have a deadly disease with a very expensive cure and don’t have time to save up to pay for it because you’d be dead by then.
I don’t see that image as very fitting. A way to work with technical debt is just killing the project at hand and building it from ground up, which really doesn’t fit your image.
It totally does; it’s like deciding your sick child/spouse should die and you’ll just replace them. Really sordid analogy but killing a project is also a terrible idea: https://www.neilgunton.com/doc/?o=tS&doc_id=8583
The analogy being sordid is one thing, the other thing is that I still don’t see how it is fitting. The article also doesn’t speak about killing, but rewriting.
Rewriting a piece of software implies killing the old code, right?
No, it means removing it. It was never alive in the first place.
I cannot use this site on Firefox for Android :( it does not respond to zooming out.