4 ms·

I’ve always viewed tech debt at related to the extent to which the system’s code and design increases the difficulty of making desired changes to it. Decisions

I’ve always viewed tech debt at related to the extent to which the system’s code and design increases the difficulty of making desired changes to it. Decisions made yesterday increasing the difficulty of making desired changes today. The important point being that it isn’t only bad decisions in the past that can cause this tech debt. While the most recognized source of tech debt is rushing to meet deadlines and taking shortcuts, changing requirements or other parts of a product can cause tech debt to manifest where there wasn’t any before. Whenever previous architecture decisions were made that you now have to work around to get what you want done, that’s tech debt. Which is I think why most people who have been in the industry for a while have a “good enough” feeling towards getting something done. Yes, you should put in an hour of work now to not have to put in ten hours of work tomorrow. But there’s no point in trying to make something perfect and debt-free for reasons beyond time efficiency. The march of time will cause a maintenance debt to accrue regardless, the difference between debt free and good enough disappears with time.

NineStarPoint 4y ago
For this reason, I think maintenance load is a bad way to think of tech debt. Time spent not working on features represents design flaws that need to be fixed…but that’s separate from how I viewed tech debt to mean something. Maybe the article writer is correct that tech debt has become too overloaded a term. But we do need a term that describes not the easily measurable maintenance costs, but the harder to measure “extent to which the code’s state slows down programmers working on it”. That people will abuse this term to describe code they don’t like working on feels inevitable though, that’s just the human condition at work unfortunately.

NineStarPoint 4y ago

For this reason, I think maintenance load is a bad way to think of tech debt. Time spent not working on features represents design flaws that need to be fixed…but that’s separate from how I viewed tech debt to mean something. Maybe the article writer is correct that tech debt has become too overloaded a term. But we do need a term that describes not the easily measurable maintenance costs, but the harder to measure “extent to which the code’s state slows down programmers working on it”. That people will abuse this term to describe code they don’t like working on feels inevitable though, that’s just the human condition at work unfortunately.