14 ms·

Is “Investing in improving structure” better than “Paying off technical debt”?

192 points by BerislavLopac 7y ago

altacc 7y ago
I agree. It’s amazing how important a choice of words can be. The word debt has negative connotations for many people, perhaps even hints of irresponsibility (e.g. you should have done it properly in the first place). It’s not always possible or efficient to educate non-technical colleagues, so I find that using more business oriented language really helps with getting that work accepted as meaningful. Even within the team, highlighting the benefits of the work leads to a more positive approach (although at the developer level we love removing terrible code, so don’t need much motivation).
tyingq 7y ago
I have noticed that business folks roll their eyes when "tech debt" comes up. I sympathize, as it didn't used to be that way. COBOL on a mainframe would remain current for decades. Tools and languages are very fragmented these days. I recently tried to get a popular node.js app (tech radar) up and running, but npm just kept bombing out on abandoned packages. The project is 2 years old and already "debt ridden". Funny, because it's all client side/ browser JavaScript. Node isn't really needed, but that's the toolchain. So it's borked for no good reason.
- noelwelsh 7y ago
  The interesting kind of technical debt is when you realize you modeled the problem wrong, or the problem has changed and you need to change the model. A simple example is an auth system that assumes a one-to-one correspondence between account and user login. Then you get, for examples, agencies that are conceptually one account but have multiple logins (so each client can only see their own account). Oops, that breaks the model. Changing this requires database migration, code changes, UX changes, and so on. It's a conceptually simple change but has wide implications.
  - tyingq 7y ago
    Business folks are more sympathetic to that kind of tech debt. The eye rolling is more around silly plumbing, version upgrades, etc, that add no business value. The React ecosystem is a good example to me. No two shops use the same stack. And alternatives like Angular are more "batteries included" and stable / "good enough to get the job done". But less popular.
  - glic3rinu 7y ago
    I wouldn’t categorize this as technical debt unless you’ve deriberatly choosen to implement the wrong abstraction first, to get the product out the door earlier, or some other short term benefit. Technical debt is a deliberate action with some upfront knowledge of its consequences.
- tarr11 7y ago
  “It didn’t used to be this way” because of the internet. Not because the way COBOL programs were developed were inherently superior. Once these cobol powered servers were accessible to hacking, “not changing anything” no longer worked. https://www.computerworld.com/article/3181809/cobol-plays-major-role-in-us-government-breaches.amp.html https://www.computerworld.com/article/3181809/cobol-plays-ma...
  - tyingq 7y ago
    I get your point, but it feels like things have swung too far in the opposite direction. Compared to other engineering (chemical, civil, industrial, etc), we do a lot of change for little good reason. There's too many ways to solve the same problem, which kills "best practice".
- BurningFrog 7y ago
  In general I don't think tech debt should be communicated to the business people. It's an internal part of engineering work, and doesn't impact users. You can think of this as "encapsulation" if you like. Also what it sounds like to outsiders is "we're taking time off to fix things we didn't bother to do right in the first place". And that's not *100% wrong...
  - tyingq 7y ago
    They are paying for it, so I'm not clear on how you hide it. They'll figure it out, and you look disingenuous when they do.
    - TeMPOraL 7y ago
      I understand GP as saying that if business people know about technical debt, it means you're giving them too much details. Business people care about features being implemented and bugs being fixed; they don't (shouldn't) care if implementing a feature is 1/3 direct work on the feature, and 2/3 fixing the architecture to make the direct work on this and future features faster - but if you communicate this split to them, they'll start asking if you couldn't cut that 2/3 part out.
      - BurningFrog 7y ago
        Thanks for explaining my point better than I would have :)
      - kd5bjo 7y ago
        I mostly agree with this in theory, but there’s a tragedy of the commons problem when working on a development team. A developer who takes the quick-and-dirty route will appear more productive in the short term than one who tries to maintain long-term development velocity. If they’re working on a shared codebase together, the latter developer will end up cleaning up the mess left by the former and getting less recognition from management. In all likelihood, this developer will either leave due to resentment, be laid off for underperformance, or stop doing the maintenance work. In any case, there’s no longer anyone seeing to the long-term development velocity and the team’s productivity will slowly grind to a halt.
- wwn_se 7y ago
  Back then technology could set more boundaries than today. Most of these old mainframe systems I have worked with, use batch jobs (running at night when the system is offline) today being offline is often not acceptable and the users can't wait until the next job to have their data in the system. But I agree that being conservative with pulling in new technologies and dependencies, new and good is not the same. I think the biggest thing with tech dept is communication. We can do this in 1 sprint but then it will cost more in the future. If business always choose the quick matter how you put it and explain when it causes problems, yeah... :(
- mwfunk 7y ago
  This makes me think part of the problem with tech debt is that it means different things to different people. Some people might describe it as a codebase just not keeping up with this month's latest and greatest JS frameworks, but I think of it as something much more nefarious- low level shittiness and incoherency that tends to seep into long-lived large projects over time. Eventually the lack of refactoring to account for new features or behaviors turns it into a giant blob of spaghetti, where everything knows about everything and what should be minor, localized changes can have unforeseen consequences. This is harder to deal with IMO because it's something that appears so slowly that it's hard to stop in isolated instances ("WTF, you wanna rewrite this whole class instead of just commenting out that one line and adding one more tiny code path to fix this bug right now?!?"). That type of technical debt is more of a boiling frog problem where it's not obvious to everyone how bad it is until serious consequences have started to arise.
  - tyingq 7y ago
    Well said, and often an artifact of "agile" where shortcuts are rewarded.
    - defined 7y ago
      Great point!
  - rdiddly 7y ago
    Maybe instead of "paying off tech debt" we should sell it as "frog-cooling." I'm only half joking. They'll respond to that by saying "WTF?" and you can be like "Yeah the frog's been in the pot not realizing it's heating up, and is about to boil." Gives it some urgency.
- bcrosby95 7y ago
  Java is pretty good at this. Before jigsaw we had projects that we hadn't touched for 13 years and they still compiled on the newest versions. There's positives and negatives to this of course.
- alacombe 7y ago
  > COBOL on a mainframe would remain current for decades Only if the underlying problem solved by the program doesn't change for decades, and even if this case, the piece of software in question is a constrain to the industry using it. I'm sure a dentist would loves to have some fancy REST 4.0 BUZZ-WORD-OF-THE-DAY client management system. I am using some industry "standard" industrial CNC software and it not only constrains me to 15 years old hardware but also restrict me to use programming quirk specific to this software which very much qualify as being "tech debt". In this case, the business is built around the software.
- closeparen 7y ago
  There's really a few distinct concepts here, and I think it's important to be precise. - Keeping up with platform churn. How much of this you will do is really a CTO level choice, in terms of a) permitting internal platform teams to break backwards compatibility, and b) permitting adoption of trendy technology from outside. - Knowingly trading off quality for speed to meet a deadline. This is tech debt in the strictest sense and you can quantify it as you accumulate it. Tech debt comes from a business / product management choice to force a project to release before it meets standards. - Seeing better abstractions and decompositions, new test cases, observability hooks, etc. with the benefit of hindsight and experience. Examples: we found four bugs in this module this quarter and it's really complex, I see a simpler and less error-prone way to rewrite it. There's a lot of interest in adding new features with a certain shape and each time you have to touch code in three different places, let me consolidate those so you only have to touch one. People keep asking a particular question that requires painstaking correlation of different logs, let's add a new logging topic that answers it directly. Stuff like this. These are never strictly necessary and business impact is hard to quantify, but if you do this stuff never, you're going to have a lot of cruft in a few years.
- Aeolun 7y ago
  I’ve recently been reading ‘A deepness in the sky’ and it has the concept of ‘Programmer-Archeologists’ exactly for this reason. It’s set many thousands of years in the future and I have trouble imagining how many old versions of packages and libraries would exist at that point.
  - WrtCdEvrydy 7y ago
    Trust me, in 20-30 years, after the apocalypse, someone needs to turn on a water filter and npm can't download the correct package... and they die of dehydration... just write the Black Mirror episode around it!
- Vinnl 7y ago
  I've got Javascript projects of a couple of years old. There are certainly things I'd do differently now if I were to set them up today, but I wouldn't consider that technical debt: those things are not giving me practical problems in the foreseeable future. The only of such projects that I'm still running which does have significant technical debt, from my point of view, is the one I set up without a CI system and without a package manager with a lock file (those didn't exist back then) - I cannot update that code today, because I cannot build it. Rewriting that one with a reproducible build set up is something I consider tech debt and which is still on my TODO list of intending to solve one day.
al2o3cr 7y ago
Disagree - "investing" is an activity that can be deferred without anything but opportunity cost; "paying off debt" expresses that not doing it has real consequences.
- PopeDotNinja 7y ago
  You shouldn't prioritize buying a fire suppression system over putting out the fire that is melting production :)
- afterburner 7y ago
  Those consequences can be small and extremely delayed if interest rates are low.
  - delecti 7y ago
    Which is one more point in favor of calling it that. Some tech debt can be put off forever, other tech debt has very high interest rates.
- mwfunk 7y ago
  That's how I think about it, and that's hopefully how a lot of people think about it, but I suspect for most people that's not true. For a lot of people debt isn't nearly as scary as it ought to be, and the idea of, instead of paying off debt, spending money to theoretically make more money seems like much more of a sure thing than it actually is. Perfect example: I'm in SV, and I bet there's a not insignificant slice of the population around me who think that the cure to budget deficits (i.e., debt) is to reduce income by cutting taxes, based on a mystical belief never seen in reality that the growth fueled by the tax cuts will result in both lower taxes for the population and higher tax revenues for the government (i.e., investment). I'm almost 50 years old, and there has never been one iota of truth to this notion in my lifetime. Not one teeny tiny iota. But some people just can't resist going back to that well over and over again with the same results every time. The notion that you can kill two birds with one stone, and both ignore debt and create wealth at the same time via magic Austrian fairy dust must be very powerful. It's like a black hole of self-evident idiocy that people keep flying into for some reason. It must be a form of cognitive bias, but if so I don't know what to call it.
joejerryronnie 7y ago
Our marketing team understands the power of framing a concept in a favorable light as they are constantly correcting our use of "eating our own dog food" to "drinking our own champagne". Of course, I paraphrase this to "drinking our own dog food".
- goatinaboat 7y ago
  Eating your own dog food is a reference to https://en.wikipedia.org/wiki/Alpo_(pet_food)#Marketing https://en.wikipedia.org/wiki/Alpo_(pet_food)#Marketing I’m surprised marketing guys don’t know that
  - detaro 7y ago
    One can easily know what it is a reference to and think it's bad framing.
lostdog 7y ago
Coming up with better terms for "tech debt" seems like a good exercise. Here are some: Improving the flexibility of our code base. Investing in future execution speed. Performing final cleanup tasks on the previous round of features. Also, when a report comes and asks for time for "refactoring," I ask them what they want to improve. Having a particular goal or target area for the refactor makes it more successful, and has the side benefit of making it easier to communicate the benefits to the rest of the company.
- JumpCrisscross 7y ago
  > Coming up with better terms for "tech debt" seems like a good exercise Something like "optimization" or "refining" might carry more traction. Nobody likes paying debt, and businesses typically make payments on debt out of obligation. (Same for cleaning up.) "Improving...flexibility" and "future execution speed" are better, but they imply nothing is gained today.
- NullPrefix 7y ago
  >Performing final cleanup tasks on the previous round of features. This implies that the previous round is not actually finished
  - TeMPOraL 7y ago
    As it should, honestly. What's really happening is that, usually due to deadlines, a job is left unfinished, and the undone tasks (like cleanup, optimization) are then labeled as "debt" just in order to push a ticket do "Done" earlier.
- nipponese 7y ago
  I agree, the narrative is important. Cleaning up "technical debt" may sound like a big cost and delayed eng schedule with no clear benefit for non-eng teams, despite being crucial to day to day operations.
jayd16 7y ago
I agree more with some of the replied about calling out direct product value instead of rebranding to another even more vague concept. It's a lot easier to sell bug fixes, stability or performance over a vague "debt/investment" that may or may not be noticable to stakeholders.
drewcoo 7y ago
When anything except new features is called "tech debt" I think Ward Cunningham's analogy has been stretched too far. It's supposed to mean forgoing needed work now with the intent to do it later. People should balk at unexpected bugs or unplanned refactoring being called that.
- Forge36 7y ago
  Occasionally the new feature's debt is never paid. I'm cleaning up a location which has had this happen 30+ times over 20 years. It resulted in 15+ sightly different ways of doing the same thing. Much of this without a function call in sight. I've been splitting functions out of it slowly reducing the 80+ variables into discrete behaviors. It's now unit testable. I'm often asked why can't I add something quickly, pointing to this file is more than enough reason for all but the most important projects to agree to wait. What should I call this if not Technical Debt?
  - ebcode 7y ago
    Not sure, but "hubris" sounds pretty good.
  - regularfry 7y ago
    It is tech debt, it just wasn't taken on as a debt intentionally. It's like going wild with a credit card - it's debt, but there was no rational thought as to what the consequences would be or how it would be repaid.
toast0 7y ago
You don't pay off technical debt. At best, you refinance it. Unless you're ending features, products, or companies.
- dmurray 7y ago
  Or dependencies.
simonw 7y ago
I love the metaphor of technical debt - you take it on with your eyes open, and sometimes you chose to pay it down. But... in larger engineering organizations I've found that "paying off technical debt" isn't actually a particularly useful goal - because teams can use it as an excuse to work on pretty much anything! If a team spends three months rewriting some code into a different style that they prefer, is that a useful pay down of debt? So - I prefer more targeted debt repayment. The best approach I've seen so far is to focus on "get rid of duplicate systems". If you have two systems that solve a particular problem and you knock that down to one, you're guaranteed to have improved things - and it's very easy to explain to non-technical stakeholders why having one system is better than having to maintain two.
- cactus2093 7y ago
  > The best approach I've seen so far is to focus on "get rid of duplicate systems" In my experience this still requires finding the right balance, like almost anything else in programming. If you're too eager to get rid of duplication you can end up combining things that aren't actually quite the same and creating leaky abstractions that are a lot more painful than the almost-duplication was. There's also sometimes a trade-off involved. Maintaining two very similar systems can be more work/require more engineers, but maintaining one system that is used in different ways can make you more likely to introduce bugs unexpectedly if you make a change focused on one particular use without testing all the others enough. It might depend on the particular system which cost is more acceptable.
  - simonw 7y ago
    Yeah I've definitely seen people refactor code to eliminate duplication in a way that turns out to be counter-productive a few weeks later, when it turns out the two places that use the code are evolving in different directions. I'm thinking more about duplicate systems. A really common pattern in a codebase that has been around for a few years is incomplete replacements: someone builds v2 of the checkout flow, but it never quite completely reaches feature parity with v1 for all of the edge cases so both of them stuck around. Kill those!
hevi_jos 7y ago
Of course, if you like to lie to outsiders so they don't really don't know how fcked your code is, it is a better term, along with: -calling "restructuring the debt" when you are broke -"negative growth" when the economy goes down -"let people go" when you fire people -"termination of pregnancy" to tear off the head of a fetus while she is alive. Technical debt is the necessary bad that programmers create because of live's realities. The only problem is that when you start telling lies to others, you could end up believing it yourself. Also the people you tell lies to could get fed up of your constant lies, distrust you and consider you just a piece of crp,just like politicians.
thanhhaimai 7y ago
I only use the term "Tech Debt" among engineering team. For communicating to a broader audience, I use: "Improve product, engineering, and operational excellence". The idea is that the broader audience focus is on the overall benefits and costs, not on whether we have debt. This phrase also allows me to make process changes that improves the team's efficiency outside of Tech Debt.
BerislavLopac 7y ago
In a way, one could argue that there is no such thing as "technical debt". This term usually denotes technical decisions which lead to functional software at a cost of now difficulty in future development, debugging, performance etc. But that cost only matters only when it's actually collected, e.g. when later development is actually difficult because of those decisions. Which might never come to pass, and activities to"improve" the codebase are wasted unless one is 100% certain that it will happen. It might be better to consider that practice "fixing non-functional bugs".
massung 7y ago
The problem here is the mischaracterization of what technical debt is. Most of the time I hear programmers talk about technical debt, what they really mean is profiling and performance (because over time requirements change and code size increases) or code "cleanup" which is usually a catch-all for "not how I would have done it". Performance issues are real, but those should just be scheduled and tackled as needed. Code cleanup is quite often a red herring. But technical debt is entirely different. It's exactly what the name implies: debt. We would have done X to implement a given feature or customer request, because there are many conditions and other systems to take into account. But there wasn't time to do it that way before the required deadline, so we did something else instead that would get by for now, but we all know won't last. That is technical debt. Sadly, often times management just see the issue as done on the schedule and there should therefore be no need to go back and "do it again". Always pay down technical debt when you can. It will be paid eventually, it's just a question of how painful it will be when you do.
- tome 7y ago
  Yes, it's extremely strange that people are looking for new terminology because they've been using the existing, perfectly good, terminology incorrectly.
- TeMPOraL 7y ago
  How's that meaningfully different than performance and code cleanup cases? Frequently, a team know how to implement a feature in an efficient manner, but only has time for a low-performance hack job. Similarly, "code cleanup" is as much a code word for "not how I would have done it" as it is for "bad architecture that will start constraining us very soon".
  - massung 7y ago
    Performance work is no different than new features: requirements change. Code cleanup can mean many things. When talking about architecture, it could be a legit argument that due to requirement changes there needs to be a rethink. But that's not debt. That wasn't a conscious decision made in the past to do A instead of B knowing that B was the right choice, but not realistic at the moment. When talking about large code bases that have been around, code cleanup is a young person's term that tends to imply they are smarter or know more than the previous set of programmers who worked on it. That's possible, but a bad argument. And it's insulting. Obviously the code has worked for quite a while successfully, so it can't be as bad as it's being made it to be (that's management playing devil's advocate). If it hasn't been working, the schedule should reflect fixing it. Maybe that requires a massive recoding, but maybe not.
jsdalton 7y ago
I have for the most part stopped using the term technical debt, especially when talking to non engineers. There are many reasons why I believe it is an exceptionally poor term, not the least of which being that, unlike monetary debt, technical debt is not quantifiable. Imagine approaching your CFO and convincing him to take out financing to fund an upcoming project, and bring completely unable to tell him the principal amount, the interest or the terms of repayment. I’ve certainly never seen any organization buy into the metaphor deeply enough that they were capable of reasoning about it with anything close to such financial permission. The term I prefer and use quite frequently these days is “technical health.” As in, choosing to continue to the next project without refactoring the new features that we rushed to deliver will negative impact technical health. Technically unhealthy code or services are slow, complex, unreliable, not performant and cumbersome. Technically healthy services allow us to be nimble, to make changes with ease and speed. They are easy to work with and easy to reason about, particularly when things go wrong.
- regularfry 7y ago
  It should be quantifiable to within an order of magnitude or so, although possibly not in advance. In my experience the problem is that any individual piece of technical debt is too small for it to seem to be worth the effort for the difference knowing the value would make.
philwelch 7y ago
Sometimes, and it also drives better decisions that way. If you have code that’s janky in some way but requires little maintenance or will be outright replaced in the near future, letting it remain janky is a reasonable decision.
bacon_waffle 7y ago
Lately I've been talking about technical rent, for instance updating a local fork of an external codebase, and feel like that distinction helps my group more thoughtfully use the technical debt metaphor.
bobbonew 7y ago
I got hired as a project manager to oversee the 5 programmers on a massive project once. Their previous “supervisor” was the owner/ceo with NO technical background for about 14 months. Every single feature and block of code was written in 30% the time it should have been given. The ceo had no idea the technical debt he was creating until it was too late. The day I came aboard any new feature or change that could be completed in 100% standard time needed 200%+ the standard time to account for the shortcuts taken over the previous 14 months. It was a total shit show and a half. The company shut down 6 months later.
- fancyfish 7y ago
  How did you approach your role as PM, aware of the tech debt but also reporting to an unaware CEO? Power through with new features at half the speed, or try to convince the CEO to allow refactoring/maintenance?
  - bobbonew 7y ago
    Sorry for the delayed response (no notification on mobile). For some reason my relationship with the ceo was viewed as trusting whereas their programming team was not. I was able to get the time required (in 9 out of 10 situations) by explaining in detail why it was required. We actually had a complete rewrite in the pipeline - an architecture written by myself - that was on the table. But they shut down before that was possible. I don’t regret taking the position despite the frustration and difficult inherent to what I had to tackle. I got a very closeup view on technical debt that has assisted me throughout my entire career.
SideburnsOfDoom 7y ago
Define "Investing in improving structure" - Of code? of system architecture? of teams and of company? Define "is x better than y" - are we talking about comparing two different activities, or is the question about different ways to name the same subject? Is it better because it's a more productive activity, or because "if you do y, you'll also get x as a side-effect" ? I'm sorry, without much clearer phrasing, the question is hopelessly ill-posed to me. Can't answer something that could mean anything.
clumsysmurf 7y ago
The problem I have with opportunistic refactoring, in the context of Scrum at least, is usually the extent of the cleanup is not known until you start making changes. By that time, you have already given an estimate for the story points. Hopefully, the business considers this a forecast. Unfortunately, many times this is considered a commitment. If you do the refactor, you may miss your commitment, and easily measurable things for the business (your velocity) look bad while something that was not easily measured (tech debt) remains unquantifiable and unchanged either way.
- regularfry 7y ago
  That version of Scrum is horrible, and should be fixed. Scrum switched "commitment" to "forecast" in 2011, and it should be well known by now that you can't compare velocity across teams, or even within the same team out past a couple of sprints.
bboreham 7y ago
In financial terms, it’s more like you sold an unhedged put option. I.e. you may be required to pay the difference, at some point in the future, not of your choosing.
PeterisP 7y ago
IMHO there are parallels with "physical" engineering if you look carefully. Here are some examples: 1) We figure out that asbestos is bad, mmkay. Now suddenly half of the buildings have a need to perform expensive maintenance work even though their business needs for "features" have not changed - that's analogous to finding a security vulnerability in a subsystem or protocol that's not even your own but that your system uses, where fixing that may take a lot of work. 2) For electric wiring. You may have a building wired properly according to code requirements as it was in 1950. Nowadays we have a better understanding of what's safe and not, and while you're often not required to fix that immediately, in many places you wouldn't be allowed to "just" do minor changes - if you do alterations, then after you're done that place must be meet the current code requirements, which may require extensive expensive work. This has a clear analogy to the type of technical debt caused by relying on an obsolete version of some dependency - adding small new stuff may force you to do integration work so that your system works with a newer version of that dependency. 3) Another example of electric wiring - you may sometimes encounter improper work done that way to save time or money because of some urgent deadline. And you can't just come in and make up the missing parts later - fixing it often requires simply ripping all of it out and putting in the wires properly; so if it's not a temporary place that's up for demolishing soon (just as with software, temporary structures also sometimes stay used much, much longer than planned) then you need to re-do it eventually if you want to keep using it safely. And there are cases just like that in software. People handling construction and reconstruction projects, as well as all their customers, have some understanding of these concepts when it applies to the physical world, and it's not that surprising to them (well, the costs for the tasks mentioned above are sometimes unpleasantly surprising) - so perhaps we should frame it in similar terminology to piggyback off of these analogies instead of debt?
- alacombe 7y ago
  Or the company can't source the same materials / quality as before (supplier change, company moves, etc) and need to go into trouble fulfilling existing orders with the old design (paying extra both time and money for the old material) while trying to sort out a new design with the new material available...
eloff 7y ago
They're both good. Stop trying to reduce a multivariate problem to a single variable problem. Managing a software project, leading a team, running a company, raising children are multivariate problems. There is no right answer or best tradeoff in all circumstances. Everything is highly context dependent and there's a balance. You have to walk that line and be careful not to stray too far to either side in everything. You can be too assertive, you can not be assertive enough. You can focus too much on technical debt, but you can also not spend enough resources addressing it and have it cost you more in the long run. Find the balance. Thats what leadership, and more broadly, life, is all about.
cjfd 7y ago
Recently I was asked to come up with a word for this kind of thing and after some thinking I settled on 'reliability'. So now we sometimes spend a bit of time on 'reliability' which sounds pretty nice, doesn't it?
leoc 7y ago
Reposting my old comment: https://news.ycombinator.com/item?id=7951964 https://news.ycombinator.com/item?id=7951964 > I don't see why the analogy to debt is necessary when the direct analogy is to capital underinvestment: in fact what we're talking about is or very nearly is just that, capital underinvestment, not simply something analogous to it. And the hypothetical businessy, non-technical types whom the debt analogy is intended to enlighten understand very clearly what deferring capital investment is and what the likely consequences are, at least if they actually know anything much about business. msandford's reply https://news.ycombinator.com/item?id=7951978 https://news.ycombinator.com/item?id=7951978 was good: > Most of the people who are pushing for "features now, someone else's problem later" are probably not upper management but rather middle management. Upper management might understand capital underinvestment. Capital underinvestment is very nearly the sole job middle management is there for. And berating people for not being done yet. At least at a couple of the places I've worked.
- peteretep 7y ago
  > when the direct analogy is to capital underinvestment https://www.google.co.uk/search?hl=en&gl=en&q="capital+underinvestment"+-"human+capital" https://www.google.co.uk/search?hl=en&gl=en&q="capital+under... (479 results) That's because you've just made the term up. If you meant instead "the underinvestment problem", then that's actually the opposite -- that's avoidance of pursuing new features because it'll incur technical debt.
- acjohnson55 7y ago
  Have you managed before? Because after becoming a first-line manager, I grew a much, much greater appreciation for middle management.
danbmil99 7y ago
In my experience, technical debt is much more about time-to-market minimization than it is about reducing costs. Here in Silicon Valley, raising capital is usually not the limiting factor. However, the spoils to be had by being first to Market are so great that they justify pushing a lot of pain into the future just to be the first to get the product out the door and get the first-mover advantage. I've observed that often programmers in the trenches I don't really understand the dynamics of the business well enough to be trusted to make critical decisions regarding these trade-offs.
peteretep 7y ago
As anyone who's had the misfortune to be involved in commercial decisions will know: > Investing in [something that sounds like infrastructure] CapEx > Paying off technical debt OpEx See also: https://twitter.com/swiftonsecurity/status/642790836955013120 https://twitter.com/swiftonsecurity/status/64279083695501312...
Fr0styMatt88 7y ago
The whole technical debt discussion often makes me wonder if there's a fundamental distrust (or even disrespect) of software engineers as domain experts. Do people in other professions have the same issues? If the salespeople say this thing must be done in this particular way, or if the lawyers say this thing must be done in this particular way, are they questioned and overridden by their managers? I honestly don't know; it feels like software engineers are given a special level of distrust but it just might be that I'm perceiving that because I haven't experienced the other jobs. FWIW where I currently work, we have an amazing middle-manager / product owner who has to fight the same battles with upper management with regards to process improvement and technical debt. She gets it, but has to fight the same battles we do. Sales and C-level want everything now with as little investment as possible.... I wonder if I just answered my own question?
- bsaul 7y ago
  From my experience, managers tend to start to distrusts software engineers after the first complete system rewrite, that was supposed to solve the big problems, actually didn’t solve them and brought new ones instead.
  - arcturus17 7y ago
    Maybe that’s one more reason why, paraphrasing Spolsky, you don’t do big system rewrites and instead carefully refactor the system bit by bit?
- mathattack 7y ago
  The issue is neither has crossed the bridge. The non-technical manager can’t understand the risks, and the engineers can’t quantity it in the dollars and cents that CFOs understand. Salespeople are good at dollars and cents. So are some lawyers. But they get overruled all the time by execs. “I don’t care how you do it, increase sales by 20% in Q4” creates the sales and marketing version of tech debt. (Channel stuffing, excess discounting, etc)
- mobjack 7y ago
  I distrust my fellow software engineers when they say they need time to pay tech debt. There were many times where I refactored code that never received any additional updates or to have the feature removed. I wasted a lot of time without any real gain for it. There are real costs to paying off tech debt and it is easy for engineers to spend their time on low value refactoring. Software engineers are not always good at prioritizing the business value side of their work so they aren't trusted there. If you can show you can prioritize business value then it is easier to convince management to give you two weeks to clean up tech debt.
quickthrower2 7y ago
Yes, because the debt analogy is strained: Debt: * Interest is due on a periodic basis, with consequences if you default such as recovery, court, reposession, bankruptcy. * You may be asked to pay back the principal on a trigger (e.g. margin call) depending on the contract, or you may have to pay towards it each month (repayment mortgage) "Tech Debt": * No pressure to repay * There is arguably a recurring cost to having bad structure, but this cost varies based on the amount of activity on the codebase. No new features and only security bug fixes = very little interest and no new tech debt. This is unlike regular debt. * Can't really be measured accurately (like real debt). * If the company is sold it is not on the books. So it's sort of like debt, but not exactly.
debrice 7y ago
I don’t believe you can answer that question... or that this question has an answer. I read a few assumptions that technical debt can be due to bad coding practice. While it could be, in my experience it often comes from business goals changing, rendering some past infrastructure obsolete or improper. There is also a lot of value for engineers to deal with debt. If dealing with debt is hard, it probably will make your team better.
deleted 7y ago
[deleted]
rdlecler1 7y ago
That We have the ability to have technical credit to draw down on shows the power of software and is valuable because it means you don’t necessarily need to build robust code to get something up and functional and it gives you an opportunity to learn.
davio 7y ago
I make people put money in the swear jar when they say "Tech Debt"

192 points by BerislavLopac 7y ago

I agree. It’s amazing how important a choice of words can be. The word debt has negative connotations for many people, perhaps even hints of irresponsibility (e.g. you should have done it properly in the first place). It’s not always possible or efficient to educate non-technical colleagues, so I find that using more business oriented language really helps with getting that work accepted as meaningful. Even within the team, highlighting the benefits of the work leads to a more positive approach (although at the developer level we love removing terrible code, so don’t need much motivation).

tyingq 7y ago

I have noticed that business folks roll their eyes when "tech debt" comes up. I sympathize, as it didn't used to be that way. COBOL on a mainframe would remain current for decades. Tools and languages are very fragmented these days. I recently tried to get a popular node.js app (tech radar) up and running, but npm just kept bombing out on abandoned packages. The project is 2 years old and already "debt ridden". Funny, because it's all client side/ browser JavaScript. Node isn't really needed, but that's the toolchain. So it's borked for no good reason.

noelwelsh 7y ago
The interesting kind of technical debt is when you realize you modeled the problem wrong, or the problem has changed and you need to change the model. A simple example is an auth system that assumes a one-to-one correspondence between account and user login. Then you get, for examples, agencies that are conceptually one account but have multiple logins (so each client can only see their own account). Oops, that breaks the model. Changing this requires database migration, code changes, UX changes, and so on. It's a conceptually simple change but has wide implications.
- tyingq 7y ago
  Business folks are more sympathetic to that kind of tech debt. The eye rolling is more around silly plumbing, version upgrades, etc, that add no business value. The React ecosystem is a good example to me. No two shops use the same stack. And alternatives like Angular are more "batteries included" and stable / "good enough to get the job done". But less popular.
- glic3rinu 7y ago
  I wouldn’t categorize this as technical debt unless you’ve deriberatly choosen to implement the wrong abstraction first, to get the product out the door earlier, or some other short term benefit. Technical debt is a deliberate action with some upfront knowledge of its consequences.
tarr11 7y ago
“It didn’t used to be this way” because of the internet. Not because the way COBOL programs were developed were inherently superior. Once these cobol powered servers were accessible to hacking, “not changing anything” no longer worked. https://www.computerworld.com/article/3181809/cobol-plays-major-role-in-us-government-breaches.amp.html https://www.computerworld.com/article/3181809/cobol-plays-ma...
- tyingq 7y ago
  I get your point, but it feels like things have swung too far in the opposite direction. Compared to other engineering (chemical, civil, industrial, etc), we do a lot of change for little good reason. There's too many ways to solve the same problem, which kills "best practice".
BurningFrog 7y ago
In general I don't think tech debt should be communicated to the business people. It's an internal part of engineering work, and doesn't impact users. You can think of this as "encapsulation" if you like. Also what it sounds like to outsiders is "we're taking time off to fix things we didn't bother to do right in the first place". And that's not *100% wrong...
- tyingq 7y ago
  They are paying for it, so I'm not clear on how you hide it. They'll figure it out, and you look disingenuous when they do.
  - TeMPOraL 7y ago
    I understand GP as saying that if business people know about technical debt, it means you're giving them too much details. Business people care about features being implemented and bugs being fixed; they don't (shouldn't) care if implementing a feature is 1/3 direct work on the feature, and 2/3 fixing the architecture to make the direct work on this and future features faster - but if you communicate this split to them, they'll start asking if you couldn't cut that 2/3 part out.
    - BurningFrog 7y ago
      Thanks for explaining my point better than I would have :)
    - kd5bjo 7y ago
      I mostly agree with this in theory, but there’s a tragedy of the commons problem when working on a development team. A developer who takes the quick-and-dirty route will appear more productive in the short term than one who tries to maintain long-term development velocity. If they’re working on a shared codebase together, the latter developer will end up cleaning up the mess left by the former and getting less recognition from management. In all likelihood, this developer will either leave due to resentment, be laid off for underperformance, or stop doing the maintenance work. In any case, there’s no longer anyone seeing to the long-term development velocity and the team’s productivity will slowly grind to a halt.
wwn_se 7y ago
Back then technology could set more boundaries than today. Most of these old mainframe systems I have worked with, use batch jobs (running at night when the system is offline) today being offline is often not acceptable and the users can't wait until the next job to have their data in the system. But I agree that being conservative with pulling in new technologies and dependencies, new and good is not the same. I think the biggest thing with tech dept is communication. We can do this in 1 sprint but then it will cost more in the future. If business always choose the quick matter how you put it and explain when it causes problems, yeah... :(
mwfunk 7y ago
This makes me think part of the problem with tech debt is that it means different things to different people. Some people might describe it as a codebase just not keeping up with this month's latest and greatest JS frameworks, but I think of it as something much more nefarious- low level shittiness and incoherency that tends to seep into long-lived large projects over time. Eventually the lack of refactoring to account for new features or behaviors turns it into a giant blob of spaghetti, where everything knows about everything and what should be minor, localized changes can have unforeseen consequences. This is harder to deal with IMO because it's something that appears so slowly that it's hard to stop in isolated instances ("WTF, you wanna rewrite this whole class instead of just commenting out that one line and adding one more tiny code path to fix this bug right now?!?"). That type of technical debt is more of a boiling frog problem where it's not obvious to everyone how bad it is until serious consequences have started to arise.
- tyingq 7y ago
  Well said, and often an artifact of "agile" where shortcuts are rewarded.
  - defined 7y ago
    Great point!
- rdiddly 7y ago
  Maybe instead of "paying off tech debt" we should sell it as "frog-cooling." I'm only half joking. They'll respond to that by saying "WTF?" and you can be like "Yeah the frog's been in the pot not realizing it's heating up, and is about to boil." Gives it some urgency.
bcrosby95 7y ago
Java is pretty good at this. Before jigsaw we had projects that we hadn't touched for 13 years and they still compiled on the newest versions. There's positives and negatives to this of course.
alacombe 7y ago
> COBOL on a mainframe would remain current for decades Only if the underlying problem solved by the program doesn't change for decades, and even if this case, the piece of software in question is a constrain to the industry using it. I'm sure a dentist would loves to have some fancy REST 4.0 BUZZ-WORD-OF-THE-DAY client management system. I am using some industry "standard" industrial CNC software and it not only constrains me to 15 years old hardware but also restrict me to use programming quirk specific to this software which very much qualify as being "tech debt". In this case, the business is built around the software.
closeparen 7y ago
There's really a few distinct concepts here, and I think it's important to be precise. - Keeping up with platform churn. How much of this you will do is really a CTO level choice, in terms of a) permitting internal platform teams to break backwards compatibility, and b) permitting adoption of trendy technology from outside. - Knowingly trading off quality for speed to meet a deadline. This is tech debt in the strictest sense and you can quantify it as you accumulate it. Tech debt comes from a business / product management choice to force a project to release before it meets standards. - Seeing better abstractions and decompositions, new test cases, observability hooks, etc. with the benefit of hindsight and experience. Examples: we found four bugs in this module this quarter and it's really complex, I see a simpler and less error-prone way to rewrite it. There's a lot of interest in adding new features with a certain shape and each time you have to touch code in three different places, let me consolidate those so you only have to touch one. People keep asking a particular question that requires painstaking correlation of different logs, let's add a new logging topic that answers it directly. Stuff like this. These are never strictly necessary and business impact is hard to quantify, but if you do this stuff never, you're going to have a lot of cruft in a few years.
Aeolun 7y ago
I’ve recently been reading ‘A deepness in the sky’ and it has the concept of ‘Programmer-Archeologists’ exactly for this reason. It’s set many thousands of years in the future and I have trouble imagining how many old versions of packages and libraries would exist at that point.
- WrtCdEvrydy 7y ago
  Trust me, in 20-30 years, after the apocalypse, someone needs to turn on a water filter and npm can't download the correct package... and they die of dehydration... just write the Black Mirror episode around it!
Vinnl 7y ago
I've got Javascript projects of a couple of years old. There are certainly things I'd do differently now if I were to set them up today, but I wouldn't consider that technical debt: those things are not giving me practical problems in the foreseeable future. The only of such projects that I'm still running which does have significant technical debt, from my point of view, is the one I set up without a CI system and without a package manager with a lock file (those didn't exist back then) - I cannot update that code today, because I cannot build it. Rewriting that one with a reproducible build set up is something I consider tech debt and which is still on my TODO list of intending to solve one day.

al2o3cr 7y ago

Disagree - "investing" is an activity that can be deferred without anything but opportunity cost; "paying off debt" expresses that not doing it has real consequences.

PopeDotNinja 7y ago
You shouldn't prioritize buying a fire suppression system over putting out the fire that is melting production :)
afterburner 7y ago
Those consequences can be small and extremely delayed if interest rates are low.
- delecti 7y ago
  Which is one more point in favor of calling it that. Some tech debt can be put off forever, other tech debt has very high interest rates.
mwfunk 7y ago
That's how I think about it, and that's hopefully how a lot of people think about it, but I suspect for most people that's not true. For a lot of people debt isn't nearly as scary as it ought to be, and the idea of, instead of paying off debt, spending money to theoretically make more money seems like much more of a sure thing than it actually is. Perfect example: I'm in SV, and I bet there's a not insignificant slice of the population around me who think that the cure to budget deficits (i.e., debt) is to reduce income by cutting taxes, based on a mystical belief never seen in reality that the growth fueled by the tax cuts will result in both lower taxes for the population and higher tax revenues for the government (i.e., investment). I'm almost 50 years old, and there has never been one iota of truth to this notion in my lifetime. Not one teeny tiny iota. But some people just can't resist going back to that well over and over again with the same results every time. The notion that you can kill two birds with one stone, and both ignore debt and create wealth at the same time via magic Austrian fairy dust must be very powerful. It's like a black hole of self-evident idiocy that people keep flying into for some reason. It must be a form of cognitive bias, but if so I don't know what to call it.

joejerryronnie 7y ago

Our marketing team understands the power of framing a concept in a favorable light as they are constantly correcting our use of "eating our own dog food" to "drinking our own champagne". Of course, I paraphrase this to "drinking our own dog food".

goatinaboat 7y ago
Eating your own dog food is a reference to https://en.wikipedia.org/wiki/Alpo_(pet_food)#Marketing https://en.wikipedia.org/wiki/Alpo_(pet_food)#Marketing I’m surprised marketing guys don’t know that
- detaro 7y ago
  One can easily know what it is a reference to and think it's bad framing.

lostdog 7y ago

Coming up with better terms for "tech debt" seems like a good exercise. Here are some: Improving the flexibility of our code base. Investing in future execution speed. Performing final cleanup tasks on the previous round of features. Also, when a report comes and asks for time for "refactoring," I ask them what they want to improve. Having a particular goal or target area for the refactor makes it more successful, and has the side benefit of making it easier to communicate the benefits to the rest of the company.

JumpCrisscross 7y ago
> Coming up with better terms for "tech debt" seems like a good exercise Something like "optimization" or "refining" might carry more traction. Nobody likes paying debt, and businesses typically make payments on debt out of obligation. (Same for cleaning up.) "Improving...flexibility" and "future execution speed" are better, but they imply nothing is gained today.
NullPrefix 7y ago
>Performing final cleanup tasks on the previous round of features. This implies that the previous round is not actually finished
- TeMPOraL 7y ago
  As it should, honestly. What's really happening is that, usually due to deadlines, a job is left unfinished, and the undone tasks (like cleanup, optimization) are then labeled as "debt" just in order to push a ticket do "Done" earlier.
nipponese 7y ago
I agree, the narrative is important. Cleaning up "technical debt" may sound like a big cost and delayed eng schedule with no clear benefit for non-eng teams, despite being crucial to day to day operations.

jayd16 7y ago

I agree more with some of the replied about calling out direct product value instead of rebranding to another even more vague concept. It's a lot easier to sell bug fixes, stability or performance over a vague "debt/investment" that may or may not be noticable to stakeholders.

drewcoo 7y ago

When anything except new features is called "tech debt" I think Ward Cunningham's analogy has been stretched too far. It's supposed to mean forgoing needed work now with the intent to do it later. People should balk at unexpected bugs or unplanned refactoring being called that.

Forge36 7y ago
Occasionally the new feature's debt is never paid. I'm cleaning up a location which has had this happen 30+ times over 20 years. It resulted in 15+ sightly different ways of doing the same thing. Much of this without a function call in sight. I've been splitting functions out of it slowly reducing the 80+ variables into discrete behaviors. It's now unit testable. I'm often asked why can't I add something quickly, pointing to this file is more than enough reason for all but the most important projects to agree to wait. What should I call this if not Technical Debt?
- ebcode 7y ago
  Not sure, but "hubris" sounds pretty good.
- regularfry 7y ago
  It is tech debt, it just wasn't taken on as a debt intentionally. It's like going wild with a credit card - it's debt, but there was no rational thought as to what the consequences would be or how it would be repaid.

toast0 7y ago

You don't pay off technical debt. At best, you refinance it. Unless you're ending features, products, or companies.

dmurray 7y ago
Or dependencies.

simonw 7y ago

I love the metaphor of technical debt - you take it on with your eyes open, and sometimes you chose to pay it down. But... in larger engineering organizations I've found that "paying off technical debt" isn't actually a particularly useful goal - because teams can use it as an excuse to work on pretty much anything! If a team spends three months rewriting some code into a different style that they prefer, is that a useful pay down of debt? So - I prefer more targeted debt repayment. The best approach I've seen so far is to focus on "get rid of duplicate systems". If you have two systems that solve a particular problem and you knock that down to one, you're guaranteed to have improved things - and it's very easy to explain to non-technical stakeholders why having one system is better than having to maintain two.

cactus2093 7y ago
> The best approach I've seen so far is to focus on "get rid of duplicate systems" In my experience this still requires finding the right balance, like almost anything else in programming. If you're too eager to get rid of duplication you can end up combining things that aren't actually quite the same and creating leaky abstractions that are a lot more painful than the almost-duplication was. There's also sometimes a trade-off involved. Maintaining two very similar systems can be more work/require more engineers, but maintaining one system that is used in different ways can make you more likely to introduce bugs unexpectedly if you make a change focused on one particular use without testing all the others enough. It might depend on the particular system which cost is more acceptable.
- simonw 7y ago
  Yeah I've definitely seen people refactor code to eliminate duplication in a way that turns out to be counter-productive a few weeks later, when it turns out the two places that use the code are evolving in different directions. I'm thinking more about duplicate systems. A really common pattern in a codebase that has been around for a few years is incomplete replacements: someone builds v2 of the checkout flow, but it never quite completely reaches feature parity with v1 for all of the edge cases so both of them stuck around. Kill those!

hevi_jos 7y ago

Of course, if you like to lie to outsiders so they don't really don't know how fcked your code is, it is a better term, along with: -calling "restructuring the debt" when you are broke -"negative growth" when the economy goes down -"let people go" when you fire people -"termination of pregnancy" to tear off the head of a fetus while she is alive. Technical debt is the necessary bad that programmers create because of live's realities. The only problem is that when you start telling lies to others, you could end up believing it yourself. Also the people you tell lies to could get fed up of your constant lies, distrust you and consider you just a piece of crp,just like politicians.

thanhhaimai 7y ago

I only use the term "Tech Debt" among engineering team. For communicating to a broader audience, I use: "Improve product, engineering, and operational excellence". The idea is that the broader audience focus is on the overall benefits and costs, not on whether we have debt. This phrase also allows me to make process changes that improves the team's efficiency outside of Tech Debt.

BerislavLopac 7y ago

In a way, one could argue that there is no such thing as "technical debt". This term usually denotes technical decisions which lead to functional software at a cost of now difficulty in future development, debugging, performance etc. But that cost only matters only when it's actually collected, e.g. when later development is actually difficult because of those decisions. Which might never come to pass, and activities to"improve" the codebase are wasted unless one is 100% certain that it will happen. It might be better to consider that practice "fixing non-functional bugs".

massung 7y ago

The problem here is the mischaracterization of what technical debt is. Most of the time I hear programmers talk about technical debt, what they really mean is profiling and performance (because over time requirements change and code size increases) or code "cleanup" which is usually a catch-all for "not how I would have done it". Performance issues are real, but those should just be scheduled and tackled as needed. Code cleanup is quite often a red herring. But technical debt is entirely different. It's exactly what the name implies: debt. We would have done X to implement a given feature or customer request, because there are many conditions and other systems to take into account. But there wasn't time to do it that way before the required deadline, so we did something else instead that would get by for now, but we all know won't last. That is technical debt. Sadly, often times management just see the issue as done on the schedule and there should therefore be no need to go back and "do it again". Always pay down technical debt when you can. It will be paid eventually, it's just a question of how painful it will be when you do.

tome 7y ago
Yes, it's extremely strange that people are looking for new terminology because they've been using the existing, perfectly good, terminology incorrectly.
TeMPOraL 7y ago
How's that meaningfully different than performance and code cleanup cases? Frequently, a team know how to implement a feature in an efficient manner, but only has time for a low-performance hack job. Similarly, "code cleanup" is as much a code word for "not how I would have done it" as it is for "bad architecture that will start constraining us very soon".
- massung 7y ago
  Performance work is no different than new features: requirements change. Code cleanup can mean many things. When talking about architecture, it could be a legit argument that due to requirement changes there needs to be a rethink. But that's not debt. That wasn't a conscious decision made in the past to do A instead of B knowing that B was the right choice, but not realistic at the moment. When talking about large code bases that have been around, code cleanup is a young person's term that tends to imply they are smarter or know more than the previous set of programmers who worked on it. That's possible, but a bad argument. And it's insulting. Obviously the code has worked for quite a while successfully, so it can't be as bad as it's being made it to be (that's management playing devil's advocate). If it hasn't been working, the schedule should reflect fixing it. Maybe that requires a massive recoding, but maybe not.

jsdalton 7y ago

I have for the most part stopped using the term technical debt, especially when talking to non engineers. There are many reasons why I believe it is an exceptionally poor term, not the least of which being that, unlike monetary debt, technical debt is not quantifiable. Imagine approaching your CFO and convincing him to take out financing to fund an upcoming project, and bring completely unable to tell him the principal amount, the interest or the terms of repayment. I’ve certainly never seen any organization buy into the metaphor deeply enough that they were capable of reasoning about it with anything close to such financial permission. The term I prefer and use quite frequently these days is “technical health.” As in, choosing to continue to the next project without refactoring the new features that we rushed to deliver will negative impact technical health. Technically unhealthy code or services are slow, complex, unreliable, not performant and cumbersome. Technically healthy services allow us to be nimble, to make changes with ease and speed. They are easy to work with and easy to reason about, particularly when things go wrong.

regularfry 7y ago
It should be quantifiable to within an order of magnitude or so, although possibly not in advance. In my experience the problem is that any individual piece of technical debt is too small for it to seem to be worth the effort for the difference knowing the value would make.

philwelch 7y ago

Sometimes, and it also drives better decisions that way. If you have code that’s janky in some way but requires little maintenance or will be outright replaced in the near future, letting it remain janky is a reasonable decision.

bacon_waffle 7y ago

Lately I've been talking about technical rent, for instance updating a local fork of an external codebase, and feel like that distinction helps my group more thoughtfully use the technical debt metaphor.

bobbonew 7y ago

I got hired as a project manager to oversee the 5 programmers on a massive project once. Their previous “supervisor” was the owner/ceo with NO technical background for about 14 months. Every single feature and block of code was written in 30% the time it should have been given. The ceo had no idea the technical debt he was creating until it was too late. The day I came aboard any new feature or change that could be completed in 100% standard time needed 200%+ the standard time to account for the shortcuts taken over the previous 14 months. It was a total shit show and a half. The company shut down 6 months later.

fancyfish 7y ago
How did you approach your role as PM, aware of the tech debt but also reporting to an unaware CEO? Power through with new features at half the speed, or try to convince the CEO to allow refactoring/maintenance?
- bobbonew 7y ago
  Sorry for the delayed response (no notification on mobile). For some reason my relationship with the ceo was viewed as trusting whereas their programming team was not. I was able to get the time required (in 9 out of 10 situations) by explaining in detail why it was required. We actually had a complete rewrite in the pipeline - an architecture written by myself - that was on the table. But they shut down before that was possible. I don’t regret taking the position despite the frustration and difficult inherent to what I had to tackle. I got a very closeup view on technical debt that has assisted me throughout my entire career.

SideburnsOfDoom 7y ago

Define "Investing in improving structure" - Of code? of system architecture? of teams and of company? Define "is x better than y" - are we talking about comparing two different activities, or is the question about different ways to name the same subject? Is it better because it's a more productive activity, or because "if you do y, you'll also get x as a side-effect" ? I'm sorry, without much clearer phrasing, the question is hopelessly ill-posed to me. Can't answer something that could mean anything.

clumsysmurf 7y ago

The problem I have with opportunistic refactoring, in the context of Scrum at least, is usually the extent of the cleanup is not known until you start making changes. By that time, you have already given an estimate for the story points. Hopefully, the business considers this a forecast. Unfortunately, many times this is considered a commitment. If you do the refactor, you may miss your commitment, and easily measurable things for the business (your velocity) look bad while something that was not easily measured (tech debt) remains unquantifiable and unchanged either way.

regularfry 7y ago
That version of Scrum is horrible, and should be fixed. Scrum switched "commitment" to "forecast" in 2011, and it should be well known by now that you can't compare velocity across teams, or even within the same team out past a couple of sprints.

bboreham 7y ago

In financial terms, it’s more like you sold an unhedged put option. I.e. you may be required to pay the difference, at some point in the future, not of your choosing.

PeterisP 7y ago

IMHO there are parallels with "physical" engineering if you look carefully. Here are some examples: 1) We figure out that asbestos is bad, mmkay. Now suddenly half of the buildings have a need to perform expensive maintenance work even though their business needs for "features" have not changed - that's analogous to finding a security vulnerability in a subsystem or protocol that's not even your own but that your system uses, where fixing that may take a lot of work. 2) For electric wiring. You may have a building wired properly according to code requirements as it was in 1950. Nowadays we have a better understanding of what's safe and not, and while you're often not required to fix that immediately, in many places you wouldn't be allowed to "just" do minor changes - if you do alterations, then after you're done that place must be meet the current code requirements, which may require extensive expensive work. This has a clear analogy to the type of technical debt caused by relying on an obsolete version of some dependency - adding small new stuff may force you to do integration work so that your system works with a newer version of that dependency. 3) Another example of electric wiring - you may sometimes encounter improper work done that way to save time or money because of some urgent deadline. And you can't just come in and make up the missing parts later - fixing it often requires simply ripping all of it out and putting in the wires properly; so if it's not a temporary place that's up for demolishing soon (just as with software, temporary structures also sometimes stay used much, much longer than planned) then you need to re-do it eventually if you want to keep using it safely. And there are cases just like that in software. People handling construction and reconstruction projects, as well as all their customers, have some understanding of these concepts when it applies to the physical world, and it's not that surprising to them (well, the costs for the tasks mentioned above are sometimes unpleasantly surprising) - so perhaps we should frame it in similar terminology to piggyback off of these analogies instead of debt?

alacombe 7y ago
Or the company can't source the same materials / quality as before (supplier change, company moves, etc) and need to go into trouble fulfilling existing orders with the old design (paying extra both time and money for the old material) while trying to sort out a new design with the new material available...

eloff 7y ago

They're both good. Stop trying to reduce a multivariate problem to a single variable problem. Managing a software project, leading a team, running a company, raising children are multivariate problems. There is no right answer or best tradeoff in all circumstances. Everything is highly context dependent and there's a balance. You have to walk that line and be careful not to stray too far to either side in everything. You can be too assertive, you can not be assertive enough. You can focus too much on technical debt, but you can also not spend enough resources addressing it and have it cost you more in the long run. Find the balance. Thats what leadership, and more broadly, life, is all about.

cjfd 7y ago

Recently I was asked to come up with a word for this kind of thing and after some thinking I settled on 'reliability'. So now we sometimes spend a bit of time on 'reliability' which sounds pretty nice, doesn't it?

leoc 7y ago

Reposting my old comment: https://news.ycombinator.com/item?id=7951964 https://news.ycombinator.com/item?id=7951964 > I don't see why the analogy to debt is necessary when the direct analogy is to capital underinvestment: in fact what we're talking about is or very nearly is just that, capital underinvestment, not simply something analogous to it. And the hypothetical businessy, non-technical types whom the debt analogy is intended to enlighten understand very clearly what deferring capital investment is and what the likely consequences are, at least if they actually know anything much about business. msandford's reply https://news.ycombinator.com/item?id=7951978 https://news.ycombinator.com/item?id=7951978 was good: > Most of the people who are pushing for "features now, someone else's problem later" are probably not upper management but rather middle management. Upper management might understand capital underinvestment. Capital underinvestment is very nearly the sole job middle management is there for. And berating people for not being done yet. At least at a couple of the places I've worked.

peteretep 7y ago
> when the direct analogy is to capital underinvestment https://www.google.co.uk/search?hl=en&gl=en&q="capital+underinvestment"+-"human+capital" https://www.google.co.uk/search?hl=en&gl=en&q="capital+under... (479 results) That's because you've just made the term up. If you meant instead "the underinvestment problem", then that's actually the opposite -- that's avoidance of pursuing new features because it'll incur technical debt.
acjohnson55 7y ago
Have you managed before? Because after becoming a first-line manager, I grew a much, much greater appreciation for middle management.

danbmil99 7y ago

In my experience, technical debt is much more about time-to-market minimization than it is about reducing costs. Here in Silicon Valley, raising capital is usually not the limiting factor. However, the spoils to be had by being first to Market are so great that they justify pushing a lot of pain into the future just to be the first to get the product out the door and get the first-mover advantage. I've observed that often programmers in the trenches I don't really understand the dynamics of the business well enough to be trusted to make critical decisions regarding these trade-offs.

peteretep 7y ago

As anyone who's had the misfortune to be involved in commercial decisions will know: > Investing in [something that sounds like infrastructure] CapEx > Paying off technical debt OpEx See also: https://twitter.com/swiftonsecurity/status/642790836955013120 https://twitter.com/swiftonsecurity/status/64279083695501312...

Fr0styMatt88 7y ago

The whole technical debt discussion often makes me wonder if there's a fundamental distrust (or even disrespect) of software engineers as domain experts. Do people in other professions have the same issues? If the salespeople say this thing must be done in this particular way, or if the lawyers say this thing must be done in this particular way, are they questioned and overridden by their managers? I honestly don't know; it feels like software engineers are given a special level of distrust but it just might be that I'm perceiving that because I haven't experienced the other jobs. FWIW where I currently work, we have an amazing middle-manager / product owner who has to fight the same battles with upper management with regards to process improvement and technical debt. She gets it, but has to fight the same battles we do. Sales and C-level want everything now with as little investment as possible.... I wonder if I just answered my own question?

bsaul 7y ago
From my experience, managers tend to start to distrusts software engineers after the first complete system rewrite, that was supposed to solve the big problems, actually didn’t solve them and brought new ones instead.
- arcturus17 7y ago
  Maybe that’s one more reason why, paraphrasing Spolsky, you don’t do big system rewrites and instead carefully refactor the system bit by bit?
mathattack 7y ago
The issue is neither has crossed the bridge. The non-technical manager can’t understand the risks, and the engineers can’t quantity it in the dollars and cents that CFOs understand. Salespeople are good at dollars and cents. So are some lawyers. But they get overruled all the time by execs. “I don’t care how you do it, increase sales by 20% in Q4” creates the sales and marketing version of tech debt. (Channel stuffing, excess discounting, etc)
mobjack 7y ago
I distrust my fellow software engineers when they say they need time to pay tech debt. There were many times where I refactored code that never received any additional updates or to have the feature removed. I wasted a lot of time without any real gain for it. There are real costs to paying off tech debt and it is easy for engineers to spend their time on low value refactoring. Software engineers are not always good at prioritizing the business value side of their work so they aren't trusted there. If you can show you can prioritize business value then it is easier to convince management to give you two weeks to clean up tech debt.

quickthrower2 7y ago

Yes, because the debt analogy is strained: Debt: * Interest is due on a periodic basis, with consequences if you default such as recovery, court, reposession, bankruptcy. * You may be asked to pay back the principal on a trigger (e.g. margin call) depending on the contract, or you may have to pay towards it each month (repayment mortgage) "Tech Debt": * No pressure to repay * There is arguably a recurring cost to having bad structure, but this cost varies based on the amount of activity on the codebase. No new features and only security bug fixes = very little interest and no new tech debt. This is unlike regular debt. * Can't really be measured accurately (like real debt). * If the company is sold it is not on the books. So it's sort of like debt, but not exactly.

debrice 7y ago

I don’t believe you can answer that question... or that this question has an answer. I read a few assumptions that technical debt can be due to bad coding practice. While it could be, in my experience it often comes from business goals changing, rendering some past infrastructure obsolete or improper. There is also a lot of value for engineers to deal with debt. If dealing with debt is hard, it probably will make your team better.

deleted 7y ago

[deleted]

rdlecler1 7y ago

That We have the ability to have technical credit to draw down on shows the power of software and is valuable because it means you don’t necessarily need to build robust code to get something up and functional and it gives you an opportunity to learn.

davio 7y ago

I make people put money in the swear jar when they say "Tech Debt"