When a project is developed for a while, a lot of initial design decisions can become invalidated as business needs evolve. New features have to be added, and in many cases they go against original assumptions about how the project would be used. At that point you have to start making hacks and kludging new features in. This creates a lot of special cases and surprising behaviors making overall project brittle and hard to maintain. That’s what’s known as tech debt.
In an ideal world you would have time to do proper redesign to accommodate new features, clean up problems as you go, and so on. However, in reality there’s usually just not enough time to do any of that so people just pile on features at the cost of overall development becoming harder and more error prone. This is a great discussion on the subject incidentally https://medium.com/@wm/the-generation-ship-model-of-software-development-5ef89a74854b
It also covers shortcuts you take to go faster while acknowledging it’s not the correct way and you’ll have to pay that debt later on. Like if you took a loan
There’s a second-order thing going on though with tech debt that makes it different than just maintenance: Tech debt is when you address a problem in a way that makes future problems more difficult to address. So if the wire-and-tape fix is actually robust, easy to work around, and/or easy to reverse, then it wouldn’t be tech debt. But if it made it harder to unclog/clean the tap, or to fix the next leak, or install/remove things around it, then it would be like tech debt.
What’s tech debt?
When a project is developed for a while, a lot of initial design decisions can become invalidated as business needs evolve. New features have to be added, and in many cases they go against original assumptions about how the project would be used. At that point you have to start making hacks and kludging new features in. This creates a lot of special cases and surprising behaviors making overall project brittle and hard to maintain. That’s what’s known as tech debt.
In an ideal world you would have time to do proper redesign to accommodate new features, clean up problems as you go, and so on. However, in reality there’s usually just not enough time to do any of that so people just pile on features at the cost of overall development becoming harder and more error prone. This is a great discussion on the subject incidentally https://medium.com/@wm/the-generation-ship-model-of-software-development-5ef89a74854b
It also covers shortcuts you take to go faster while acknowledging it’s not the correct way and you’ll have to pay that debt later on. Like if you took a loan
“pay that debt later on”, nothings more permanent than temporary. In my experience things are more likely to default than get paid lol
In my team we pay the tech debt on the following sprints
Removed by mod
There’s a second-order thing going on though with tech debt that makes it different than just maintenance: Tech debt is when you address a problem in a way that makes future problems more difficult to address. So if the wire-and-tape fix is actually robust, easy to work around, and/or easy to reverse, then it wouldn’t be tech debt. But if it made it harder to unclog/clean the tap, or to fix the next leak, or install/remove things around it, then it would be like tech debt.
Removed by mod