[HN Gopher] Tech debt metaphor maximalism
___________________________________________________________________
Tech debt metaphor maximalism
Author : xena
Score : 99 points
Date : 2023-07-07 17:46 UTC (5 hours ago)
(HTM) web link (apenwarr.ca)
(TXT) w3m dump (apenwarr.ca)
| c-linkage wrote:
| My problem with the entire technical debt metaphor is that the
| interest payments are invisible.
|
| On an accounting sheet I can see my interest rate and how much
| I'm paying monthly and make decisions. With technical debt, it's
| all about people time, and people time is a sunk cost to your
| finance department.
| smif wrote:
| I think this is close, but I'd go even further and say that the
| problem is that with real debt anyone can see the money in
| black and white, they require no special training to be able to
| understand real debt and read the numbers off an account
| summary. There's not much room for interpretation there.
|
| With tech debt, you can ask several engineers and get very
| different answers about how much tech debt there is on a
| particular project. It's not well defined, subject to
| interpretation, and so doesn't fit well with management wanting
| quantify the objective value of doing something. I think this
| is the real reason it's often disregarded.
|
| It requires a degree of trust from management to the engineers
| to properly address, and that trust can be abused. All sides
| are aware of this and I'm sure I'm not the only one that has
| used tech debt as an excuse for some minor padding here and
| there.
| Thrio499 wrote:
| It is very exact text, but it is missing basic point:
|
| People who develop and manage the code, most likely do not own
| the debt. Code (and technical debt) belongs to stock holders. And
| there is a huge separation from developers and management.
| wpietri wrote:
| This is a nice but very long exploration of the tech debt
| metaphor, raising several excellent points. I especially like
| comparing it with the business uses of actual debt.
|
| The only thing I think I'd add to it is that like actual debt, a
| lot of people do not behave sensibly with tech debt. One of my
| big tests in any new job is the first time a product manager
| wants to put something on credit. E.g., "We have to add feature X
| right now so we can land a big client. Can we cut corners to get
| this out the door? We'll sort out the mess later."
|
| Despite things like this making my eyelid twitch, I'll always
| tell a new product manager yes the first time they ask this. But
| then I watch carefully to see if they're conscientious about
| paying down the debt. Some of them are great about it,
| prioritizing the deferred work. Others, though, always have a
| next emergency. But in my view if it's always an emergency it
| never is, and so I never again trust them with the tech-debt
| credit card.
| automatic6131 wrote:
| Tbh, cutting corners to land new revenue, if it's sufficiently
| big, sounds like the prime reason to take on tech debt. It's
| arguably just like a loan to make a new factory line to expand
| production for new sales or whatever.
|
| For sure, if it's a small client or far from a sure thing, then
| yeah it's bad. Like anything, a judgement call about where the
| cost benefit ratio lies.
| littlestymaar wrote:
| One very similarly finance-oriented comparison that I like to
| make is that every line code is a liability, in the financial
| sense of that word[1]: that's what's on the right side of your
| balance sheet, which enables your assets: that is _your product_.
|
| Like there are many ways to finance your business, there are many
| ways to make the same product, from coding it from scratch
| yourself (which ranges from "from quick and dirty" to "using
| formal methods") to customizing a open-source foundation, or even
| a third party's white-label product. Which one is better
| completely depends on the situation (like with equity vs debt).
|
| [1]:in finance, "liability" isn't "bad", debt is a liability, but
| so is equity, and even profit is a liability!
| twic wrote:
| Debt works like this:
|
| 1. you take on debt to get hold of some cash
|
| 2. at some point, you ought to repay the debt by giving up the
| same amount of cash
|
| 3. until you do, you have to spend a steady trickle of cash
| servicing the debt
|
| In the technical debt metaphor, cash stands for development
| effort. But:
|
| 1. taking on technical debt doesn't give you a load of
| development effort out of nowhere (i suppose you could say that
| shipping what should be a three week feature in two weeks is like
| getting a week of effort from nowhere, but that seems dubious to
| me - you haven't shipped the same feature!)
|
| 2. repaying technical debt generally takes more work than it
| saved, because by the time you repay it, it's infected other code
| that was written afterwards BUT sometimes you end up being able
| to delete the whole thing, because the feature was retired or
| fundamentally rewritten, in which case you don't need to repay it
| at all!
|
| 3. sometimes, existing technical debt requires no extra work at
| all (if it's in a part of the codebase you aren't touching), but
| if it does, it's not a constant amount, it's proportional to the
| amount of work you are doing on that code
|
| So it doesn't seem like a brilliant metaphor, really.
|
| Perhaps it's more like cleaning your bike chain after a ride
| through the mud. If you don't do it, it saves you some time
| today. But every time you ride your bike again, it's more effort
| to pedal, and it's wearing your chain out faster.
| xyzzy4747 wrote:
| Good engineers don't create as much tech debt in the first place,
| or if they do it's straight-forward code that's relatively easy
| to refactor. The #1 fix to prevent most serious tech debt and
| also get features done quickly is the quality of your engineers
| (or yourself if you're the one coding). Someone knowledgeable
| with several completed projects and up-to-date knowledge should
| create the codebase.
|
| Also it depends a lot on what stage your project is in. If you
| have zero customers or money coming in, your focus should be on
| creating a working product and getting customers. That means zero
| tests for now, just a working product. It will also more quickly
| validate if you're working on the right thing or not, or if you
| need to pivot.
|
| One problem I see is when engineers want to solve the tech debt
| problem before even proving the product should exist. No, first
| establish the demand, get real cash flow, then start focusing on
| tech debt.
|
| If you are an entrepreneur then tech debt is literally the last
| of your concerns. If you grow enough where it is then it's a good
| problem to have - the biggest problem is typically not enough
| customers, not too much tech debt.
|
| On the other hand if you are working at Google, and know for a
| fact thousands or millions of people will use your code, then you
| should "lock it down" right at the beginning, have all the
| testing upfront, good documentation, etc.
| twic wrote:
| There's a classic Steve Freeman joint, "bad code isn't technical
| debt, it's an unhedged call option":
|
| https://www.infoq.com/news/2014/12/call-options-bad-code/
| klysm wrote:
| And that margin call might come at a bad time
| sonofhans wrote:
| I worked with Ward Cunningham for about a year, and he said once
| that he regretted coining the phrase "technical debt." He said it
| allowed people to think of the debt in a bottomless way: once
| you've accumulated some, why not a little more? After all, the
| first little bit didn't hurt us, did it?
|
| The end result of this thinking is the feature factory, where a
| company only ever builds new features, usually to attract new
| customers. Necessary refactors are called "tech debt" and left to
| pile up. Yes, this is just another view of bad management, but
| still, Ward thought that the metaphor afforded it too easily.
|
| He said he wished instead that he'd coined "opportunity," as in,
| producing or consuming it. Good practices produce opportunity.
| Opportunity can then be consumed in order to meet certain short-
| term goals.
|
| So it flips the baseline. Rather than having a baseline of
| quality then dipping below it into tech debt, you'd produce
| opportunity to put you above the baseline. Once you have this
| opportunity, you consume it to get back to baseline but not
| below.
|
| I'm not convinced that the concept phrased thus would have the
| same traction. Still, I love this way of looking at it, like I
| love much of Ward's POV on the world.
| dasil003 wrote:
| Totally agree with that, but I don't think regret is warranted.
| The power of "technical debt" is that it was actually catchy
| enough to get a foothold with the MBAs and pointy hairs. That
| alone is a victory. Any sufficiently good idea with a catchy
| meme is subject to cargo culting and abuse. We need look no
| further than The Agile Manifesto to see how thoroughly any
| well-summarized wisdom, drawn from a well of deep expertise,
| lovingly word-smithed with the utmost clarity, can be abused
| and twisted into a hideous monstrosity that is, in fact, the
| complete opposite of the original intent.
| lumost wrote:
| I've also found that the term can be used to describe anything.
| Some folks would think of anything that isn't "shiny new
| framework" as tech debt. Some folks think of unsupported
| features as tech debt. Some folks think that the 2 million line
| monolithic code base producing billions of profit per year is
| tech debt.
|
| After seeing a few too many tech debt reduction programs yield
| even more tech debt than they started with... I simply don't
| buy retrospective arguments any more. Decide what is
| acceptable/unacceptable at design time, don't strangle yourself
| on it after the fact.
| wpietri wrote:
| Sorry, but I don't understand this. Tech debt it any mess
| that makes it harder to improve the product. You have to pay
| cost without getting any new value; the benefit for the cost
| was received previously. People may misuse the term, but it
| has a pretty clear meaning.
|
| I also don't understand what "design time" could mean these
| days. 30 years ago, when release cycles were 18-36 months, it
| was a real thing. But now? With modern release cadences, we
| are always designing the system. Which is great, because the
| quality of design is limited by our knowledge, and our
| knowledge increases over time. Setting our standards early on
| in a project, when we're most ignorant, guarantees we'll be
| setting the bar wrong.
| pydry wrote:
| I get it. People feel the pain correctly but decide the
| solution is some combination of write everything in shiny
| new framework and start linting more strictly.
| lumost wrote:
| > Setting our standards early on in a project, when we're
| most ignorant, guarantees we'll be setting the bar wrong.
|
| This seems like an artificial constraint, there are obvious
| basics such as
|
| - Code should be reviewed by N people
|
| - Testing should cover X core workflows/Y branches etc.
|
| - Dev environments should be creatable in X
| minutes/hours/days
|
| - The system should perform specific tasks (if you don't
| know what these are, then coding the system may or may not
| be the best use of time)
|
| - The system should support Y TPS at Z cost (all systems
| have a maximum scale, estimate the scale that is required).
|
| - Design should be signed off on by Y people, where Y may
| be 1 person in a small team.
|
| etc. You can find the right set of constraints for your
| domain. However a system not doing something it wasn't
| designed for isn't really tech debt in my opinion, it's
| just a new use case which needs to be built for.
| divbzero wrote:
| Sticking with the balance sheet analogy, the phrase would be
| "technical asset".
| CSMastermind wrote:
| I've always used the phrase "technical wealth" to explain the
| opposite of technical debt.
|
| But I agree your term works a little better since you can
| have both assets and liabilities and ideally you want to be
| wealthy not indebted.
| m463 wrote:
| Don't forget people use ambiguity as a tool all the time.
|
| Politicians use words like "justice" or "freedom" to create
| common ground with little controversy even when they define the
| term in a way diametrically opposed to their constituents.
|
| I think it can be the same with "tech debt".
|
| I have a friend who figures when he sells his house it will be
| a tear-down, so he has all kinds of "house tech debt" that he
| just manages to live with until he literally moves on. it
| basically means "I don't care about fixing that" or "I'm not
| going to fix that ever".
| brianpan wrote:
| * * *
| commandlinefan wrote:
| Another problem with the analogy is that you can meaningfully
| make a $0.01 payment on your debt. You can pick any arbitrary
| percentage of your debt and pay it off right now, if you have
| the money to do so. Programming tasks are not only more
| (unpredictably) quantized than that, they're usually Sisyphean:
| if you do a little but don't finish, you've wasted the time you
| spent because the boulder rolls back down as soon as you stop
| pushing.
| xedrac wrote:
| That is a good point. Tech debt is often, but not always,
| harder to pay back in small amounts.
| JJMcJ wrote:
| Enough technical debt and your project is on "technical payday
| loans". I've worked on such projects and it's no fun.
| [deleted]
| marcosdumay wrote:
| > The end result of this thinking is the feature factory
|
| I'm not sure how relevant this is, but a feature factory is the
| result of people contracting software development, and
| measuring it by features; nothing more.
|
| Any other characteristic is a consequence, not a cause.
| vinibrito wrote:
| You just expanded my mind with that today. Well, so we can
| raise above the status quo, how else would development be
| contracted?
| Jtsummers wrote:
| Include in the contract "non-functional" requirements (the
| distinction can be fuzzy with a good case to put some
| requirement in both categories, but it's a useful
| distinction nonetheless). These are things like how stable
| it is (uptime requirements, perhaps), how secure it is. How
| quickly can a new feature be delivered? This lets you
| require an organizational capability, but not a system
| feature capability. If it takes your contractor 6 months to
| deliver an update with a color change to a page background,
| something is wrong. Require more responsiveness, but also
| offer more responsiveness on your side (like if you have a
| QA/test team responsible for final sign-off or to answer
| clarification questions, etc.).
|
| You don't want to mandate their internal processes, at that
| point they're not contractors they're your employees and
| you are essentially taking over their management.
|
| EDIT: Grammar
| spacebanana7 wrote:
| Any delegation of work from one person to another involves
| a loss of context and distorts incentives. The only way out
| entirely is to build your own software to solve your own
| problems.
|
| See the principal agent problem in economics.
|
| Unfortunately subsistence software engineering isn't a
| viable profession because the productive capacity of a
| single engineer is limited. And we occasionally need
| physical stuff like food/water.
| marcosdumay wrote:
| I am wary of formal offshoring of development at all.
| Contractors can solve a few problems for small companies
| when they are also small and you have a trusting long term
| relationship. On any other context, contracting seems to
| always fail.
|
| But the specific format of specifying the software,
| contract it away, and pay for feature size leads to the
| specific kind of failure that we call "feature factory".
| NoMoreNicksLeft wrote:
| > I worked with Ward Cunningham for about a year, and he said
| once that he regretted coining the phrase "technical debt." He
| said it allowed people to think of the debt in a bottomless
| way: once you've accumulated some, why not a little more? After
| all, the first little bit didn't hurt us, did it?
|
| I suspect that at the foundational level of this metaphor, the
| true problem is that some/most people treat financial debt the
| same, until they're evicted and the car has been repossessed
| and they've got a warrant out for their failure to show in
| court.
|
| I want to be wrong about that. Someone tell me I'm wrong.
___________________________________________________________________
(page generated 2023-07-07 23:00 UTC)