"They know that they’re going to have to manufacture endless explanations for why seemingly simple things take them a long time."
This is what kills me. You can't say to the boss, "Your beloved senior dev built this arcane and fragile system, so everything I do takes forever." Instead you have to find diplomatic/meaningless explanations for why you're moving so slowly.
I've found that I can win over my immediate superiors with low level grumbling about real technical issues in the code base. They eventually internalize the state of the code base and have realistic expectations for how long things will take. The key is to diplomatically voice all your WTF moments, and have a boss technical enough to get it.
Problem is their bosses still think that the spaghettified joke that is the internal framework we have to use is manna from heaven and would take a very dim view of anyone caught trashing it in the open.
From the bosses' point of view it is very difficult to tell the difference between "we have a crap codebase" and "the new guy sucks at reading code and is going to want to rewrite everything he touches".
I'm convinced that the issue overall is lack of transparency about design quality. In an org with non-technical leadership, technical staff should periodically present assessments of their systems' readiness for change. Non-tech people need to understand technical debt and see how it changes over time.
In my experience, companies with technical founders tend to have cultures that handle this issue better.
Technical debt isn't a problem as long as the team has good communication & low levels of political behaviour.
IMO articles like this that paint Tech Debt as a universally negative thing (without trying to balance the view, or mention the context in which the tech exists) do more harm than good.
Update: Recommend reading "5 Dysfunctions of a Team" for guidance on improving communication and reducing political behaviour in an organisation.
Funny I get the opposite take on this article in terms of meaning, yet I still think it is off base.
"Technical Debt" is a dangerous analogy because most of what people call technical debt would best be called "ignorance" or "wishful thinking". Debt is a complex social invention that includes methods of accounting, a repayment schedule, etc.
MBA types will have to negotiate with banks, senior executives, the board, etc. about the debt taken on by a corporation.
Worse yet, ignorance often takes the form of overengineering, so what is done in the name of "saving time now" is often completely wasted.
>a complex social invention that includes methods of accounting, a repayment schedule, etc.
Isn't that the point?
There are similar reasons to take on real and technical debt, like expanding into a new market. You also come up with a "repayment schedule" for technical debt, which involves allocating time for checking/updating the documentation, refactoring code, etc.
Some people use "technical debt" to mean "no one knows how this works", but I think the actual debt there is in the documentation or the lousy quality of the code, not the ignorance.
It's a metaphor and it can definitely be taken too far. One of the abuses I don't care for is the notion that Technical Debt can be quantified and calculated for a code base. That's wrong in a number of different ways.
Agreed. It's another instance of making a tech to finance analogy that just doesn't hold up. It's really nice when you can just put a number on something. And it really sucks when you can't, but that doesn't prevent people from trying.
Why does the sales guy get to go play golf after closing a big deal? And yet the developer still has to show up and sit in his seat after he performs some equivalent wizardry? Because the sales guy's effort has a number attached to it, that's why.
My takeaway is that the crucial component of tech debt is the interest you pay on it, which often gets overlooked. It's not just that it takes longer to do tomorrow what you could do today, but you also face developer unhappiness and attrition.
This is just part of how you communicate about technical debt. It does not address the context, business interests, etc., but it doesn't need to. It doesn't imply anything about the value of debt, and discussing a negative aspect of it does not exclude what value it has.
> ... but you also face developer unhappiness and attrition.
I don't think this should be assumed. The unhappiness and stress around Tech Debt are directly caused by sub-optimal communication, not by the debt itself. The debt is just the stage on which the poor communication is played out.
