8 ms·

Reframing Tech Debt

68 points by kiyanwang 5y ago

JanisL 5y ago
After studying a lot of economics over the last few years I realized that most people have a poor understanding of the concept of debt so I stopped using the term technical debt almost entirely.
joshz404 5y ago
I like it. I’ve also found success as framing it as building tech capability. Focusing people on adding capability or wealth, positive connotations, I think is the way to go.
jeffbee 5y ago
I don't know if I like this framing at all. If your company has fostered an atmosphere where there seems to be tension between writing unit tests and shipping features, you've already screwed it up. If you divide your development schedule between shipping features and writing tests you are simply enabling the bad actors in your organization to inevitably short-change that part of the cycle.
afarrell 5y ago
I’ve worked on a team that explicitly aimed to budget about 10-20% of its time on “tech investment” projects to expand/protect our capability to deliver. We also delivered fairly predictably on business goals. It was glorious.
ahdh8f4hf4h8 5y ago
Personally, I no longer use the phrase "technical debt" when speaking to management. It's just too vague of a term. Instead I just explain the actual problem and the consequences - too much near duplicate code leading to slow maintenance, non-scalable design choices leading to slow processes, rigid design choices which hamper the team from implementing the upcoming stories, excessive complexity leading making the code hard to change. Once you get our of analogies and into actual problems, then you can have a reasonable discussion about future tradeoffs. I find even with non-technical managers, debt/wealth is just not a good analogy for code. Also, often poor code is just part of a larger process problem. You really need to optimize for the whole project, not just code-level to improve the situation.
- brightball 5y ago
  Agreed. I like to use opportunity cost to try to frame the trade offs in terms of future developer time that will have to be used to address the trade offs which won’t be focused on other development efforts.
- redroot 5y ago
  I've also found the term quite dangerously misleading. The 'tech' part of the statement makes it sound like the 'debt' that is getting in your way it's purely a concern of the engineering function, where it should be a concern of the business. The 'debt' part is also confusing - I have seen non-technical stakeholders thinking it can be dealt with like financial debt with more revenue or VC rounds in one lump sum, we don't have to worry about it because are a growing startup and debt is normal. Two alternative explanations I've begin to use over the last few years that have helped: 1) Inertia / Inert Areas - the reason this 'debt' is a problem is it means future changes are hard to execute cleanly, and previously. An area becomes inert to change unless an intervention is made. For non-technical stakeholders they most important thing is often that we can keep making changes, so this sets all sorts of loss aversion alarm bells ringing in a way the term 'debt' doesn't - this is where you can start talking about risk, which crosses the divide between engineering and other functions quite well. 2) Product Debt - Yes in some cases code is just badly written, which is an engineering concern, but often the reason changes in Year 5 are hard to make because the domain / reality has moved on, and the assumptions baked into the code written in Year 2, no matter how clean the code, are now just wrong. For example, baked-in assumptions of how business works in Market A as you are expanding into Market's B and C. This isn't the fault of engineering, just the reality of a product that continues to persist - core changes are inevitable. Product leaders therefore need to also get strategic about when it makes sense to rethink previous decisions driven by product needs, and work with engineering leaders to mitigate otherwise you might end up in an inert ball of mud unable to hit goals. In the most idealised vision of a piece of software, changes will get harder to make in a linear fashion if previous decision are not revisited will new information. In worst case it's more like an exponential graph, so intervention steps will always have to be taken. As you say, once you're talking the same language, then you get into the details about what strategies to address this inertia / current conditions.
mr_tristan 5y ago
I've found most "tech debt" planning to be incredibly vague and nebulous. Many engineers can identify what makes them uncomfortable, but it takes real effort to fully explain why, and what the real impacts are. Maybe trying to think about "tech wealth" or "tech capability" might change this. Instead of a ticket to "improve error handling" it's "ensure the system can recover from a DNS failure safely to the DB without manual intervention". This sounds more like a feature, because, well, it is. I've found most of the places talk a lot about having good quality, but few actually did anything concrete about it. Most changes ended up not making any impact. And this is over the course of a 20 year career.
- Ocerge 5y ago
  I agree. Tech debt planning reduces down to x% spent on "fixing bugs" which never works (or at least I've never seen it work). Explicitly engineering fixes to actual definable problems is the best solution, but it takes effort. Complaining is a lot easier :)
sktrdie 5y ago
I'm curious how largish software projects are organized to deal with tech debt. Is it just ingrained and taken into account for say 20% of the work at each sprint planning? Is there a specific team dedicated to doing tech debt stuff? Do people just work on tech debt when they feel like it? Are there just a few people in the team that like to go around the project and take on smallish tech debt tasks? I'm curious because our team is struggling with tech debt. We are divided in feature teams and I had this idea of maybe simply having a "tech debt team" that, just like feature teams, has sprints achieving tech-debt related goals such as "improve startup times by 10%" or "decouple router module from auth module" or "setup webpack to tree-shake modules" etc. How do y'all do it?
- taeric 5y ago
  I've rarely seen directly working on tech debt actually pay off. You either get stuck fixing last year's problem, or you lose the race to feature parity with where you were. To that end, keep cleaning as you go. And accept that good development can be like a good batter. Probabilistically good. Not certain.
- ahdh8f4hf4h8 5y ago
  I have always done "just in time" refactoring - when a big change comes to a module and you're going to have to re-test most of it anyways, then perform the refactor, test the code/module, and then implement the actual change. It helps if you have some long term vision for the product, so you have some idea of future changes as well. You want to avoid refactoring if no one else is going to test the change, or if your automated test coverage on the module isn't too good. It's too easy to introduce changes that won't be noticed before deployment. Chances are most code already works well enough even if the design or code is suboptimal - often the system only changes in certain parts and changes there often. If you can identify the parts of your system that are likely to change due to changes in scale or business requirement, than that is a natural area to focus on in future redesigns or refactoring.
  - convolvatron 5y ago
    this is right. in particular its timely and easy to justify if you can reasonably argue that new priority work would benefit from the refactoring of adjacent components.
wpietri 5y ago
I think this is a mistake a lot of people make: > Carving out time to pay down tech debt requires buy-in from leadership. Not in my experience! I think one can do pretty well a) refusing to put debt in to begin with, and b) for any new work, including necessary cleanup of what you'll be touching in the estimates. Some years back I had an explicit understanding with a product manager: the engineers would track tech debt and take care of it in small slices over time. He could always ask for details, but absent his curiosity, we'd just leave him out of it, doing a little bit every week so that things always stayed in good enough shape that we would keep our velocity high and our surprises low. Early on he asked a couple of times, but he quickly realized that to him it was entirely boring. I think it's a mistake to ask non-experts to prioritize things they don't understand. You're not going to ask your execs if it's ok for you to take time to eat or brush your teeth. You equally shouldn't ask them if it's ok to be a responsible professional and do things like writing tests and keeping the code base reasonably clean. That should just be part of the deal; any exceptions should be temporary and carefully negotiated.
- infogulch 5y ago
  This is my preferred strategy, but gets muddled when managers micro-manage code reviews. Maybe that's just a sign of a toxic work environment. > You're not going to ask your execs if it's ok for you to take time to eat or brush your teeth. I like this! I could add: machine shop workers don't ask if it's ok to clean up the mess after a job.
  - lowercased 5y ago
    A machine shop 'mess' is often obvious, and the risks are usually obvious and understood by most or all parties as well. It's not often the case with software (or... has not been in my experience).
- Lhiw 5y ago
  I've never liked the small slice approach. It's always the first thing to be scope cut whent time is running out. I prefer to just do refactors before work starts, or during the work itself. I have run into managers that read how to work with legacy code and think everything we do should be one line changes and major refactors mean we're basically doing rewrites. I still work there. Sometimes.
legerdemain 5y ago
Is this the final issue of Increment? Has Stripe decided what, if anything, will replace it?
- edwinwee 5y ago
  It is—in its current form as a print quarterly. If you have any feedback on what we should do next, let us know here: https://forms.gle/PbzM7Ndmb9iLN8Tq5 https://forms.gle/PbzM7Ndmb9iLN8Tq5.
wellpast 5y ago
“Tech debt” is the software industry’s way of euphemistically describing their incompetence. It’s a way to act like one “meant” to implement a shitty architecture instead of admitting one’s lack of ability and experience. It’s the mantra of the expert beginner of which there are so many. You think I’m wrong, but you know I’m right because you can’t define it with any precision no matter how hard you try.
- yourapostasy 5y ago
  > ...because you can’t define it with any precision no matter how hard you try. For my clients, when we discuss "tech debt", I give it to them in concrete terms. "You want Capability A at Month 3, but in order to pull that off, you're going to have to give on Requirement 1 and Expectations Lambda, and it will cost us Y months of implementation in Q4 instead of Y-2 months, will that work for the business?" "Sure." "So marked in the meeting notes, and filed under our Tech Debt Jira backlog Feature, we won't move forward with Capability A implementation until you send Sam when you need the technical debt paid off by, and we'll slot it in ahead of time, okay?" "No problem, we'll get it to you with more detailed requirements on Capability A next week, thanks!" Sure, when you don't track tech debt it is just sloppy work ("incompetence" is a little harsh, I tend to say the staff involved need more coaching and are possibly more junior than their roles require...bees, honey, and all that). It has served me well to get through to those managers who initially demand the impossible.
- outsomnia 5y ago
  > You think I’m wrong No, I was on my way to upvote your comment when I got to > but you know I’m right because you can’t define it with any precision no matter how hard you try. It's when somebody decides to optimize for one thing that temporarily mattered to them at the time, at the expense of other things that matter afterwards. Eg, having that demo next week may truly be existential for the project, but all the foundations you didn't dig and the rebar you skipped putting in to tick that box mean you cannot successfully build on it without going backwards first.
- sirwhinesalot 5y ago
  PM: "We promised higher management that feature X would be done by The Date(tm)" DEV: "We can only do that by cutting corners, reusing code for purposes we shouldn't, and making it not extensible in the future" PM" "Yeah but we promised higher management so it needs to get done" some time later... PM: "Hey can we add feature Y by The Date(tm)" DEV: "It doesn't fit with the rushed work we did for feature X, we'll need to rewrite quite a bit of code to make those two fit" PM: "Yes but we promised feature Y by The Date(tm) to this customer, so it needs to get done" DEV: "Well we can hack something together which does 90% of Y on a full moon and breaks otherwise, I really don't recommend doing this." PM: "We have no choice" some time later... PM: "Why are all features taking so much longer to complete than they used to" DEV: "Massive technical debt" PM: "Ah yes, the software industry's way of euphemistically describing their incompetence."
ravenstine 5y ago
Technical debt is a euphemism for bad code, bad practices, and bad decisions. When we use the term tech/technical debt, we are pretending that the real answer isn't "we didn't do it right the first time". The primary reason this phrase even exists is because if we told our superiors the truth then heads might roll. Non-technical people don't really understand what "technical debt" means, but the word debt at least makes some sense to them. "We need this thing done pronto. How soon can you get it done?" "Well, sir, it's gonna take at least a month. Maybe 3 weeks if we get cracking at it." "A month? But we want it ASAP. Why a month?" "Um, because there's a lot of technical debt we've got to deal with." "Uh huh... I see. OK, well, carry on then." walks away "I think he bought it, Fred."
- sirwhinesalot 5y ago
  That's some victim blaming right there. If a project has tech debt it is because of management decisions 9/10. They are the ones promising higher management some feature would get done by The Date(tm) without consulting with development if that is feasible. Development then buys time with tech debt (cutting corners, copy pasting, not writing docs/tests). Then things start getting delayed because developers are paying the "interest" (i.e. regressions due to bad tests) on that original "debt" that was paid to give management what they wanted.
  - ravenstine 5y ago
    No it isn't. Just because tech debt is the end-product doesn't at all imply that the root cause isn't management, though I can understand why it might be misinterpreted as such. > Development then buys time with tech debt (cutting corners, copy pasting, not writing docs/tests). > Then things start getting delayed because developers are paying the "interest" (i.e. regressions due to bad tests) on that original "debt" that was paid to give management what they wanted. The problem with this analogy is, unlike financial debt, said tech debt is often caused by management, and I'm sure you'd agree. Imagine trying to pay down your credit card and Visa tells you to make more purchases or else you may lose your card entirely (and still have to make your monthly payments). Does management view tech debt as something they share or are responsible for? I doubt it. What the use of "tech debt" actually does is create an artificial sense of legitimacy around all the problems that exist in a failing process. It obfuscates specifics from management, dazzling them with terminology they believe they understand. It allows developers to believe that nothing is truly their fault. It gaslights developers into seeing a counterproductive or even abusive relationship with management as just debt that they own. It'd be one thing if it actually did work like debt and, yes, I'm sure it does work that way with some teams. I don't think that's the norm.
0xbadcafebee 5y ago
The origin of tech debt is well understood among experienced development teams. If it were possible to avoid it simply by planning, then they'd simply plan to avoid it right at the beginning. It's not possible to avoid tech debt by planning because tech debt is not really an oversight. Tech debt is a direct result of the wrong priorities. The development team does not set the priorities. The team are simply the builders, like a construction team. If you tell a construction team to change what they're building in the middle of building it, your project will take longer and become more expensive, and structurally/functionally will end up worse and worse as you continue to build on something not designed for it. Or if the builders simply decide to skip vital steps to move faster, then of course debt will follow; don't install a vapor barrier in your new home and you will soon find a quite large debt after it's completed! The only way to prevent tech debt is to have good priorities and not change them mid-way. If you design it well, and have experienced developers, they can built it right the first time with no debt. But if priorities are compromised, debt will inevitably follow. In terms of the "tech wealth" listed here, what they really mean is "be able to do your job"; have the right tools and processes so you can get something done in the right amount of time. Again, that's priorities. If you don't have some automation or tool, you have two choices: you can buy it, or you can build it. Building it costs more money and takes more time - debt!! If the priority is reduction of short-term cost, the development team can't just plan around that.
Jare 5y ago
I think framing it as tech investment makes it easier for management to see it as a trade off with features. Features show the manager's work, "tech investment" by itself doesn't, so the moment there's any tension between the two, feature work will win. The important thing is to have a way to show the value of doing that work. Call it debt, wealth, or whatever. But, measure some KPIs, establish a tech debt/wealth workplan with predicted goals, execute, measure again, and use it as proof. The fight for buy-in to continue incorporating that work in the schedules and plans. The alternative is creating the work standard of having "20% of your time can go to anything you think needs fixing, no questions asked. Above that, ask first." Just like Code Reviews are no longer seen as skippable (ahem well mostly). That 20% is ALWAYS on, regardless of any deadlines, planned work, be it features, training or peer reviews.
analog31 5y ago
Maybe "technical rent" would be a better term, as it implies a recurring cost that's paid to keep something that's already been built. Managers already grasp recurring software costs.
dpeck 5y ago
If you’re getting explicit buy-in from leadership about technical debt you can be assured that whoever was in your role previously failed badly at keeping engineering aligned and in step with the overall goals of the business.
scottcodie 5y ago
It's not your boss's responsibility to write good code, they likely don't touch code at all.
jillesvangurp 5y ago
Technical debt is a bit of a fuzzy problem that is hard to explain without a lot of platitudes to a non technical person. Instead of doing that, the key to staying on top of keeping your tech stack in a sane state is to assign ownership of it to a person that knows what they are doing that can effectively counter the pressure from non technical persons in the organization to move faster. It's all about prioritizing correctly in the end and that's not a job you can give to a non technical product manager. I actually am a CTO that is also responsible for a lot of the day to day product management. So, I get to wear both hats. My job is not to blindly execute somebody else's vision but to actually create and define the vision and adjust to needs and wants of our business based on what is technically possible with our stack and ensure that that stack is ready to do so. Additionally, I need to stay ahead of this game and a lot of what we do technically is about being ready for what I can see coming next rather than just reacting to current needs. The game here is avoiding over engineering while at the same time spotting and removing technical bottlenecks. Technical product management is a thing; or rather it should be in almost any team. It's a natural progression for a technical leader to also start paying attention to what they are building and why. I've been interacting with product managers for years and have many product manager friends. Working with them instead of against them is key. Technical product management requires somebody with technical know how as well as a sense of the business and its priority. A non technical PM is the wrong person for this job. If you have such a person guarding technical quality and business alignment, things run much smoother than if you have a lot of people bickering with each other over technical perfection or doing quick fixes.

68 points by kiyanwang 5y ago

After studying a lot of economics over the last few years I realized that most people have a poor understanding of the concept of debt so I stopped using the term technical debt almost entirely.

joshz404 5y ago

I like it. I’ve also found success as framing it as building tech capability. Focusing people on adding capability or wealth, positive connotations, I think is the way to go.

jeffbee 5y ago

I don't know if I like this framing at all. If your company has fostered an atmosphere where there seems to be tension between writing unit tests and shipping features, you've already screwed it up. If you divide your development schedule between shipping features and writing tests you are simply enabling the bad actors in your organization to inevitably short-change that part of the cycle.

afarrell 5y ago

I’ve worked on a team that explicitly aimed to budget about 10-20% of its time on “tech investment” projects to expand/protect our capability to deliver. We also delivered fairly predictably on business goals. It was glorious.

ahdh8f4hf4h8 5y ago

Personally, I no longer use the phrase "technical debt" when speaking to management. It's just too vague of a term. Instead I just explain the actual problem and the consequences - too much near duplicate code leading to slow maintenance, non-scalable design choices leading to slow processes, rigid design choices which hamper the team from implementing the upcoming stories, excessive complexity leading making the code hard to change. Once you get our of analogies and into actual problems, then you can have a reasonable discussion about future tradeoffs. I find even with non-technical managers, debt/wealth is just not a good analogy for code. Also, often poor code is just part of a larger process problem. You really need to optimize for the whole project, not just code-level to improve the situation.

brightball 5y ago
Agreed. I like to use opportunity cost to try to frame the trade offs in terms of future developer time that will have to be used to address the trade offs which won’t be focused on other development efforts.
redroot 5y ago
I've also found the term quite dangerously misleading. The 'tech' part of the statement makes it sound like the 'debt' that is getting in your way it's purely a concern of the engineering function, where it should be a concern of the business. The 'debt' part is also confusing - I have seen non-technical stakeholders thinking it can be dealt with like financial debt with more revenue or VC rounds in one lump sum, we don't have to worry about it because are a growing startup and debt is normal. Two alternative explanations I've begin to use over the last few years that have helped: 1) Inertia / Inert Areas - the reason this 'debt' is a problem is it means future changes are hard to execute cleanly, and previously. An area becomes inert to change unless an intervention is made. For non-technical stakeholders they most important thing is often that we can keep making changes, so this sets all sorts of loss aversion alarm bells ringing in a way the term 'debt' doesn't - this is where you can start talking about risk, which crosses the divide between engineering and other functions quite well. 2) Product Debt - Yes in some cases code is just badly written, which is an engineering concern, but often the reason changes in Year 5 are hard to make because the domain / reality has moved on, and the assumptions baked into the code written in Year 2, no matter how clean the code, are now just wrong. For example, baked-in assumptions of how business works in Market A as you are expanding into Market's B and C. This isn't the fault of engineering, just the reality of a product that continues to persist - core changes are inevitable. Product leaders therefore need to also get strategic about when it makes sense to rethink previous decisions driven by product needs, and work with engineering leaders to mitigate otherwise you might end up in an inert ball of mud unable to hit goals. In the most idealised vision of a piece of software, changes will get harder to make in a linear fashion if previous decision are not revisited will new information. In worst case it's more like an exponential graph, so intervention steps will always have to be taken. As you say, once you're talking the same language, then you get into the details about what strategies to address this inertia / current conditions.

mr_tristan 5y ago

I've found most "tech debt" planning to be incredibly vague and nebulous. Many engineers can identify what makes them uncomfortable, but it takes real effort to fully explain why, and what the real impacts are. Maybe trying to think about "tech wealth" or "tech capability" might change this. Instead of a ticket to "improve error handling" it's "ensure the system can recover from a DNS failure safely to the DB without manual intervention". This sounds more like a feature, because, well, it is. I've found most of the places talk a lot about having good quality, but few actually did anything concrete about it. Most changes ended up not making any impact. And this is over the course of a 20 year career.

Ocerge 5y ago
I agree. Tech debt planning reduces down to x% spent on "fixing bugs" which never works (or at least I've never seen it work). Explicitly engineering fixes to actual definable problems is the best solution, but it takes effort. Complaining is a lot easier :)

sktrdie 5y ago

I'm curious how largish software projects are organized to deal with tech debt. Is it just ingrained and taken into account for say 20% of the work at each sprint planning? Is there a specific team dedicated to doing tech debt stuff? Do people just work on tech debt when they feel like it? Are there just a few people in the team that like to go around the project and take on smallish tech debt tasks? I'm curious because our team is struggling with tech debt. We are divided in feature teams and I had this idea of maybe simply having a "tech debt team" that, just like feature teams, has sprints achieving tech-debt related goals such as "improve startup times by 10%" or "decouple router module from auth module" or "setup webpack to tree-shake modules" etc. How do y'all do it?

taeric 5y ago
I've rarely seen directly working on tech debt actually pay off. You either get stuck fixing last year's problem, or you lose the race to feature parity with where you were. To that end, keep cleaning as you go. And accept that good development can be like a good batter. Probabilistically good. Not certain.
ahdh8f4hf4h8 5y ago
I have always done "just in time" refactoring - when a big change comes to a module and you're going to have to re-test most of it anyways, then perform the refactor, test the code/module, and then implement the actual change. It helps if you have some long term vision for the product, so you have some idea of future changes as well. You want to avoid refactoring if no one else is going to test the change, or if your automated test coverage on the module isn't too good. It's too easy to introduce changes that won't be noticed before deployment. Chances are most code already works well enough even if the design or code is suboptimal - often the system only changes in certain parts and changes there often. If you can identify the parts of your system that are likely to change due to changes in scale or business requirement, than that is a natural area to focus on in future redesigns or refactoring.
- convolvatron 5y ago
  this is right. in particular its timely and easy to justify if you can reasonably argue that new priority work would benefit from the refactoring of adjacent components.

wpietri 5y ago

I think this is a mistake a lot of people make: > Carving out time to pay down tech debt requires buy-in from leadership. Not in my experience! I think one can do pretty well a) refusing to put debt in to begin with, and b) for any new work, including necessary cleanup of what you'll be touching in the estimates. Some years back I had an explicit understanding with a product manager: the engineers would track tech debt and take care of it in small slices over time. He could always ask for details, but absent his curiosity, we'd just leave him out of it, doing a little bit every week so that things always stayed in good enough shape that we would keep our velocity high and our surprises low. Early on he asked a couple of times, but he quickly realized that to him it was entirely boring. I think it's a mistake to ask non-experts to prioritize things they don't understand. You're not going to ask your execs if it's ok for you to take time to eat or brush your teeth. You equally shouldn't ask them if it's ok to be a responsible professional and do things like writing tests and keeping the code base reasonably clean. That should just be part of the deal; any exceptions should be temporary and carefully negotiated.

infogulch 5y ago
This is my preferred strategy, but gets muddled when managers micro-manage code reviews. Maybe that's just a sign of a toxic work environment. > You're not going to ask your execs if it's ok for you to take time to eat or brush your teeth. I like this! I could add: machine shop workers don't ask if it's ok to clean up the mess after a job.
- lowercased 5y ago
  A machine shop 'mess' is often obvious, and the risks are usually obvious and understood by most or all parties as well. It's not often the case with software (or... has not been in my experience).
Lhiw 5y ago
I've never liked the small slice approach. It's always the first thing to be scope cut whent time is running out. I prefer to just do refactors before work starts, or during the work itself. I have run into managers that read how to work with legacy code and think everything we do should be one line changes and major refactors mean we're basically doing rewrites. I still work there. Sometimes.

legerdemain 5y ago

Is this the final issue of Increment? Has Stripe decided what, if anything, will replace it?

edwinwee 5y ago
It is—in its current form as a print quarterly. If you have any feedback on what we should do next, let us know here: https://forms.gle/PbzM7Ndmb9iLN8Tq5 https://forms.gle/PbzM7Ndmb9iLN8Tq5.

wellpast 5y ago

“Tech debt” is the software industry’s way of euphemistically describing their incompetence. It’s a way to act like one “meant” to implement a shitty architecture instead of admitting one’s lack of ability and experience. It’s the mantra of the expert beginner of which there are so many. You think I’m wrong, but you know I’m right because you can’t define it with any precision no matter how hard you try.

yourapostasy 5y ago
> ...because you can’t define it with any precision no matter how hard you try. For my clients, when we discuss "tech debt", I give it to them in concrete terms. "You want Capability A at Month 3, but in order to pull that off, you're going to have to give on Requirement 1 and Expectations Lambda, and it will cost us Y months of implementation in Q4 instead of Y-2 months, will that work for the business?" "Sure." "So marked in the meeting notes, and filed under our Tech Debt Jira backlog Feature, we won't move forward with Capability A implementation until you send Sam when you need the technical debt paid off by, and we'll slot it in ahead of time, okay?" "No problem, we'll get it to you with more detailed requirements on Capability A next week, thanks!" Sure, when you don't track tech debt it is just sloppy work ("incompetence" is a little harsh, I tend to say the staff involved need more coaching and are possibly more junior than their roles require...bees, honey, and all that). It has served me well to get through to those managers who initially demand the impossible.
outsomnia 5y ago
> You think I’m wrong No, I was on my way to upvote your comment when I got to > but you know I’m right because you can’t define it with any precision no matter how hard you try. It's when somebody decides to optimize for one thing that temporarily mattered to them at the time, at the expense of other things that matter afterwards. Eg, having that demo next week may truly be existential for the project, but all the foundations you didn't dig and the rebar you skipped putting in to tick that box mean you cannot successfully build on it without going backwards first.
sirwhinesalot 5y ago
PM: "We promised higher management that feature X would be done by The Date(tm)" DEV: "We can only do that by cutting corners, reusing code for purposes we shouldn't, and making it not extensible in the future" PM" "Yeah but we promised higher management so it needs to get done" some time later... PM: "Hey can we add feature Y by The Date(tm)" DEV: "It doesn't fit with the rushed work we did for feature X, we'll need to rewrite quite a bit of code to make those two fit" PM: "Yes but we promised feature Y by The Date(tm) to this customer, so it needs to get done" DEV: "Well we can hack something together which does 90% of Y on a full moon and breaks otherwise, I really don't recommend doing this." PM: "We have no choice" some time later... PM: "Why are all features taking so much longer to complete than they used to" DEV: "Massive technical debt" PM: "Ah yes, the software industry's way of euphemistically describing their incompetence."

ravenstine 5y ago

Technical debt is a euphemism for bad code, bad practices, and bad decisions. When we use the term tech/technical debt, we are pretending that the real answer isn't "we didn't do it right the first time". The primary reason this phrase even exists is because if we told our superiors the truth then heads might roll. Non-technical people don't really understand what "technical debt" means, but the word debt at least makes some sense to them. "We need this thing done pronto. How soon can you get it done?" "Well, sir, it's gonna take at least a month. Maybe 3 weeks if we get cracking at it." "A month? But we want it ASAP. Why a month?" "Um, because there's a lot of technical debt we've got to deal with." "Uh huh... I see. OK, well, carry on then." walks away "I think he bought it, Fred."

sirwhinesalot 5y ago
That's some victim blaming right there. If a project has tech debt it is because of management decisions 9/10. They are the ones promising higher management some feature would get done by The Date(tm) without consulting with development if that is feasible. Development then buys time with tech debt (cutting corners, copy pasting, not writing docs/tests). Then things start getting delayed because developers are paying the "interest" (i.e. regressions due to bad tests) on that original "debt" that was paid to give management what they wanted.
- ravenstine 5y ago
  No it isn't. Just because tech debt is the end-product doesn't at all imply that the root cause isn't management, though I can understand why it might be misinterpreted as such. > Development then buys time with tech debt (cutting corners, copy pasting, not writing docs/tests). > Then things start getting delayed because developers are paying the "interest" (i.e. regressions due to bad tests) on that original "debt" that was paid to give management what they wanted. The problem with this analogy is, unlike financial debt, said tech debt is often caused by management, and I'm sure you'd agree. Imagine trying to pay down your credit card and Visa tells you to make more purchases or else you may lose your card entirely (and still have to make your monthly payments). Does management view tech debt as something they share or are responsible for? I doubt it. What the use of "tech debt" actually does is create an artificial sense of legitimacy around all the problems that exist in a failing process. It obfuscates specifics from management, dazzling them with terminology they believe they understand. It allows developers to believe that nothing is truly their fault. It gaslights developers into seeing a counterproductive or even abusive relationship with management as just debt that they own. It'd be one thing if it actually did work like debt and, yes, I'm sure it does work that way with some teams. I don't think that's the norm.

0xbadcafebee 5y ago

The origin of tech debt is well understood among experienced development teams. If it were possible to avoid it simply by planning, then they'd simply plan to avoid it right at the beginning. It's not possible to avoid tech debt by planning because tech debt is not really an oversight. Tech debt is a direct result of the wrong priorities. The development team does not set the priorities. The team are simply the builders, like a construction team. If you tell a construction team to change what they're building in the middle of building it, your project will take longer and become more expensive, and structurally/functionally will end up worse and worse as you continue to build on something not designed for it. Or if the builders simply decide to skip vital steps to move faster, then of course debt will follow; don't install a vapor barrier in your new home and you will soon find a quite large debt after it's completed! The only way to prevent tech debt is to have good priorities and not change them mid-way. If you design it well, and have experienced developers, they can built it right the first time with no debt. But if priorities are compromised, debt will inevitably follow. In terms of the "tech wealth" listed here, what they really mean is "be able to do your job"; have the right tools and processes so you can get something done in the right amount of time. Again, that's priorities. If you don't have some automation or tool, you have two choices: you can buy it, or you can build it. Building it costs more money and takes more time - debt!! If the priority is reduction of short-term cost, the development team can't just plan around that.

Jare 5y ago

I think framing it as tech investment makes it easier for management to see it as a trade off with features. Features show the manager's work, "tech investment" by itself doesn't, so the moment there's any tension between the two, feature work will win. The important thing is to have a way to show the value of doing that work. Call it debt, wealth, or whatever. But, measure some KPIs, establish a tech debt/wealth workplan with predicted goals, execute, measure again, and use it as proof. The fight for buy-in to continue incorporating that work in the schedules and plans. The alternative is creating the work standard of having "20% of your time can go to anything you think needs fixing, no questions asked. Above that, ask first." Just like Code Reviews are no longer seen as skippable (ahem well mostly). That 20% is ALWAYS on, regardless of any deadlines, planned work, be it features, training or peer reviews.

analog31 5y ago

Maybe "technical rent" would be a better term, as it implies a recurring cost that's paid to keep something that's already been built. Managers already grasp recurring software costs.

dpeck 5y ago

If you’re getting explicit buy-in from leadership about technical debt you can be assured that whoever was in your role previously failed badly at keeping engineering aligned and in step with the overall goals of the business.

scottcodie 5y ago

It's not your boss's responsibility to write good code, they likely don't touch code at all.

jillesvangurp 5y ago

Technical debt is a bit of a fuzzy problem that is hard to explain without a lot of platitudes to a non technical person. Instead of doing that, the key to staying on top of keeping your tech stack in a sane state is to assign ownership of it to a person that knows what they are doing that can effectively counter the pressure from non technical persons in the organization to move faster. It's all about prioritizing correctly in the end and that's not a job you can give to a non technical product manager. I actually am a CTO that is also responsible for a lot of the day to day product management. So, I get to wear both hats. My job is not to blindly execute somebody else's vision but to actually create and define the vision and adjust to needs and wants of our business based on what is technically possible with our stack and ensure that that stack is ready to do so. Additionally, I need to stay ahead of this game and a lot of what we do technically is about being ready for what I can see coming next rather than just reacting to current needs. The game here is avoiding over engineering while at the same time spotting and removing technical bottlenecks. Technical product management is a thing; or rather it should be in almost any team. It's a natural progression for a technical leader to also start paying attention to what they are building and why. I've been interacting with product managers for years and have many product manager friends. Working with them instead of against them is key. Technical product management requires somebody with technical know how as well as a sense of the business and its priority. A non technical PM is the wrong person for this job. If you have such a person guarding technical quality and business alignment, things run much smoother than if you have a lot of people bickering with each other over technical perfection or doing quick fixes.