Debt
Most of us have some. Maybe a mortgage or a car loan. At this time of year, you might have a little credit card debt after perhaps slightly overindulging at Christmas, and after the year that was 2020 who can blame you?
But there are other kinds of debt.
We might owe friends a favour, some obligation to help them because they helped us. We may owe a huge debt to all those who have helped us become the people we are and in the positions we have.
Anyone who's been in IT for more than a week will have heard the term ‘technical debt’ and those who’ve been in IT any considerable time will have numerous stories about the impact of technical debt.
I went looking for a precise definition of technical debt, and there isn’t one. It varies depending on where you look. ITIL defines it one way, agile methodologies use another.
The one I found that closely matches my experience came from an article in The Enterprisers Project about managing technical debt.
Technical debt (TD) is a broad concept that encompasses many of the decisions made and shortcuts are taken during the software development cycle. It happens when teams are working through set tasks, updating features, and dealing with bugs – and it sometimes comes with negative consequences.
Negative outcomes caused by technical debt typically take the form of badly designed code, deterioration of productivity, additional unplanned costs, delivery delays, and degradation in the quality of the product.
I think this nicely sums it up. A lot of those shortcuts are made early in a product’s lifecycle when you’re just trying to get something working, something shippable, your MVP. Later on, you have to go back and ‘fix’ that code, make it maintainable, scalable, able to fully meet the requirements.
It’s a normal process, as the company grows we expect it.
So why do we think all the workflows and processes we started out with will work once we grow?
All those decisions made and shortcuts taken during the earlier stages of the company. Teams working just to get things done, with little thought about how, just scrambling to find some way through. Workflows put in place when you were 20 people, but now you're 200.
That’s process debt. And like technical debt all companies have it. It all slows you down, reduces productivity, causes delays, and lowers the quality of the services you provide.
Also like technical debt it won’t go away by itself. Someone needs to take it on and improve things.
You use a more experienced developer to find and remove technical debt.
Who do you have who can remove your process debt?
You put time and effort into working off technical debt, what are you doing about your process debt?
Comments