4 ms·
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
by michaelfeathers 10y ago
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.
- richmarr 10y ago> ...lack of transparency about design quality Totally agree. 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.
- PaulHoule 10y agoFunny 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.
- mattkrause 10y ago>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.
- michaelfeathers 10y agoIt'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.
- OpenDrapery 10y agoAgreed. 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.
- Obi_Juan_Kenobi 10y agoMy 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.
- richmarr 10y ago> ... 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.