10 ms·

Bad code isn’t technical debt, it’s an unhedged call option

220 points by yummyfajitas 12y ago

pavlov 12y ago
Maybe metaphors are like short-selling: unlimited future downside in exchange for potential quick gains.
- jerguismi 12y ago
  Unlimited future downside? Really? I would like to know on which context this is possible. I don't know in which context the writer is writing, I'm a developer and have been mostly working on startup-style projects. If you fail, you don't make a buck, the product does not work or does not sell. The downside is the lost time and money. I have also known couple of startups, which have had really good engineers who have invested lots to testing, maintainability etc. In the end however the business hasn't succeeded selling the product, and all that investment was worth essentially nothing.
  - pavlov 12y ago
    I was trying to make an ironic joke about the pitfalls of metaphors by using a metaphor. It didn't really have anything to do with the premise of the origīnal post. So I apologize for being off-topic - the opportunity was just too tempting :)
    - jdp23 12y ago
      And the response was a great illustration of your point. Nice self-documenting experiment :)
    - nightpool 12y ago
      Actually, I think the commentator here assumed (as I did) that you were slightly off-topic talking about the use of metaphors in software programming. I feel a little bit silly now, FWIW.
  - Dewie 12y ago
    > Unlimited future downside? Really? I would like to know on which context this is possible. Don't take it so literally; it's just a short-selling simile.
    - deleted 12y ago
      [deleted]
  - e28eta 12y ago
    How about a product that kills people: Therac-25, any other prominent examples of failures? Or destroys the users' financial well-being: software they use to run their small business, or invest their retirement?
    - deleted 12y ago
      [deleted]
    - Snail_Commando 12y ago
      http://www.fas.org/spp/starwars/gao/im92026.htm http://www.fas.org/spp/starwars/gao/im92026.htm https://en.wikipedia.org/wiki/MIM-104_Patriot#Failure_at_Dhahran https://en.wikipedia.org/wiki/MIM-104_Patriot#Failure_at_Dha... Whether or not this can be attributed to technical debt, I don't know. But it is an instance of a software failure that resulted in death.
  - abofh 12y ago
    There's also no unlimited downside in finance -- eventually you can't take out more debt, can't pay the interest, and default (creating counter party risk). I suppose net across the system, you could inflict more downside to others exposed to your default, but it's not unlimited unless you can wipe out the entire planetary economy (financial and non financial) with your bet.
- fiatmoney 12y ago
  In the normal case of short selling (absent a large enough position to be subject to a short squeeze) future downside is not unlimited; your broker will close your position unless you put up enough capital.
- bbcbasic 12y ago
  Metaphors spread confusion by taking something that is simple to understand, and translating it to another domain so that people get the wrong idea. A bit like learning to fish is better than giving a guy a fish.
dropit_sphere 12y ago
This is actually a worthy terminology switch, capturing the uncertainty of software development.
jerguismi 12y ago
"Debt is predictable and can be managed, it’s just another tool." Well, not really. For example, if you took usd-based debt in russia, you are now quite royally fucked.
- samstokes 12y ago
  That's not (only) debt, that's (also) currency speculation.
  - jacques_chester 12y ago
    So it'd be extending the analogy to bet on untested new technologies.
- cmdkeen 12y ago
  It's actually a really good example of the article - there's nothing wrong with debt denominated in a foreign currency, you can hedge against the currency risk. The whole thing is about risk, if you hedge away all your risk financially there is generally no profit to be made (you're left with arbitrage), if you hedge away all your technical debt then you've essentially (re)implemented it properly.
fcbrooklyn 12y ago
Technical debt is actually a really good analogy, precisely because non-technical finance people understand the tradeoff pretty intuitively. Sometimes incurring debt is the right thing to do, but you'll want to pay it down or you'll have to live with the interest. This is true of both monetary and technical debt. For extra credit, you might assign notional interest rates to your technical debt... if they're in the double digits I promise you they'll scare the finance guy.
- majc2 12y ago
  If you want to scare them talk about it being a technical credit card - pay that debt back regularly and try and clear it as quickly as you can.
  - lumpypua 12y ago
    Ehhh, the analogy doesn't hold totally because you might not have to pay it back. In that case you're ahead. FTA: Call options are a better model than debt for cruddy code (without tests) because they capture the unpredictability of what we do. If I slap in an a feature without cleaning up then I get the benefit immediately, I collect the premium. If I never see that code again, then I’m ahead and, in retrospect, it would have been foolish to have spent time cleaning it up.
    - fcbrooklyn 12y ago
      I agree, the analogy is imperfect, because you don't pay interest unless you need to extend or maintain the code. It's only useful in a world where the codebase in question is under ongoing development, but those are the situations where I've used it. Naked calls work fine as an analogy in the case you describe.
    - briandear 12y ago
      That's the home run point: you might not have to pay it back. That is exactly why the debt or credit card analogy doesn't hold. An uncovered call is exactly the correct metaphor. This isn't even high finance we're talking about, this is fundamental options stuff. I'm not sure I understand the resistance to using the uncovered call terminology as opposed to the highly innaccurate (but more Main Street comprehensible) "debt" analogy. Debt (aside from bankruptcy ALWAYS has to be repaid. Yet we all know that technical debt doesn't always have to be repaid. Debt is a terribly imprecise way of thinking about it.
angersock 12y ago
God, I want to short my codebase so hard. What would the engineering equivalent of that be, I wonder? Quitting and getting hired back as a consultant?
- nostromo 12y ago
  Just sell a company and codebase you've yet to create. If the market value seems greater before you've actually shipped: congrats, you just made money shorting your own company.
- mbesto 12y ago
  > God, I want to short my codebase so hard. Invest in your competitor.
  - bryanh 12y ago
    If quality of code had a causal relation with success - that might be accurate. I'm not sure it does.
    - the_cat_kittles 12y ago
      i was going to write that good code is a necessary but not sufficient condition. but thats not true either!
      - deleted 12y ago
        [deleted]
      - chii 12y ago
        success of the business and good quality code does have a relation ship - it's just not an obvious one. Like reversing a car with a trailer, the direction you want to go can be difficult to control, but it doesn't mean your driving doesn't affect it.
- curiously 12y ago
  borrow money and hire an expert contractor and fire them and claim the credit and reap the rewards.
mattvanhorn 12y ago
I worked at a place where the VPE would talk about technical debt as a mortgage. Yet they had a culture that abhorred paying down the debt through refactoring, and so it was more like one of those interest-only payment mortgages. They paid higher interest in the form of reduced productivity and speed, and ended up with the same amount of debt as when they started.
radiowave 12y ago
I've always liked this analogy in preference to the standard notion of debt, but if we find ourselves having to explain the analogy, is it such a good analogy in the first place? So I think it needs to be judged in context - who are we trying to communicate with?
gojomo 12y ago
There's something to this – the emphasis on the optionality of 'technical debt' – but it's not quite 'unhedged'. There's not an 'unlimited downside', as there can be when writing a call on an asset that could appreciate boundlessly. With tech projects there's almost always a de facto "abandon" option – if not for the firm then at least for the individual engineers. So whenever the cost of proceeding is higher than the expected value, you exit. That clips the downside, more like some sort of combined option position. Or more like a specific kind of debt: nonrecourse loans secured by collateral. You get the money up front, but if it proves impossible to repay, you simply surrender the collateral. In this case, the collateral is the project itself: either the option to continue, or the IP rights, or the enclosing firm. And, in the event of failure, those may be worth nothing, so you aren't losing an unbounded amount. For monetary debt, these fragmentary artifacts may in fact be surrendered to the creditors. In the case of metaphorical technical debt, you surrender up those hopes and dreams and mental (sunk) costs, to the reality that there won't ever be the time and budget to fix the system. And so this leads to a different conclusion than the article, which ends with a near-religious stance against the inflexible evil of debt. Because the downside – project abandonment – is capped, sometimes technical debt is worth taking on, when acceleration-to-market (and thus market-feedback-learning) is of paramount importance. You're borrowing from the future, but you only pay it back (with interest) if there's wild success. If you fail for any other reason – perhaps things having nothing to do with the technical debt – you don't have to pay it off, you just surrender the (essentially worthless) collateral. That's a hard thing for people with an aesthetic or craftsperson mentality to accept. And it still sucks when it's the technical debt itself – the cost of fixing old rushed choices – that occasionally makes a project no longer competitively viable. Your monetary credit report is unblemished, but your self-conception can take a hit.
ThisIBereave 12y ago
Maybe this works for people in finance, but I can't see it being useful otherwise. The concept you're using as an analogy just isn't widely known.
- sitharus 12y ago
  I'd agree, but the people we have to justify spending refactoring time to are often in finance.
  - morgante 12y ago
    I don't know about that. Unless you're explicitly a FinTech company, most of the business folks aren't necessarily well-versed in options markets.
- curiously 12y ago
  I totally understand this pain point before I began reading on options I was clueless, mystified but ultimately realized options are akin to trading stocks (buying low selling high) but with the added time restriction and ability to make money in any market. Options are tricky to understand but essentially, think of it as just a piece of paper or a contract between you and the person buying it from you. It's a buy/sell market that exists on these "papers". Options trading essentially revolve around buying these papers which usually have an expiry date of between weeks to years and at what price you can buy the underlying good before the expiry date. The profit is made from the valuation of this paper going up and down based on the underlying value of what this paper represents. The paper can be contract about beef, corn, oil and share price of Apple. Just like the stock market, you want to pay cheap price for a paper and sell it when it goes high, but the beauty of options is since you don't actually trade the actual good itself, you can create a dizzying array of strategies and combinations to make money in any type of situation, but with the condition that you have to be right about what market we are in (trending up, down, sidways, volatility etc). Writing an option is like selling a piece of paper that says the person buying your paper will have the ability to buy the stock at the price written on the paper. If the price is low and the stock price goes up, well you now have to buy X number of shares that was written on the paper at the high price to give to this guy, causing great deal of loss to you (since you sold the paper for some cash earlier). If the stock price falls, then you could buy the shares at the low low price using the money you made from selling the paper and give it to the other guy, who most likely won't ask you to do this and just think about the time he paid you to write him a piece of paper that is now "expired" or worthless.
dinkumthinkum 12y ago
I don't like this kind of discussion. I don't believe technical debt is a thing and I think this idea if technical debt as really straining the metaphor. This is like bike shedding.
- deleted 12y ago
  [deleted]
- jhull 12y ago
  What do you consider technical debt to be then? Just bad code?
  - briandear 12y ago
    Code (or system design) that has potential issues that may or may not need to be resolved in the future, but the benefit of not doing it now outweighs the pain of doing it later.
    - jhull 12y ago
      Right. I know what technical debt is. The commenter I replied to said "I don't believe technical debt is a thing" and was hoping (s)he would elaborate.
dragonwriter 12y ago
It may be a more accurate analogy, but its a less useful metaphor for most audiences. Most people have a useful intuition about debt that the "technical debt" metaphor leverages. Comparatively very few people have a useful intuition about "unhedged call options" that using it as a metaphor for poor code quality would leverage. Also, I think predictable ongoing support cost is a big result of poor code quality in production systems, so that aspect of the debt metaphor isn't completely off-base (there are also unpredictable potential costs in the future, as well, so its not a perfect analogy.)
lifeisstillgood 12y ago
I keep bumping into the notion of options in software development - there are (and I will try to hunt them down) a couple of well known papers on option pricing different features. It is interesting because if applied it would spread through the whole organisation using it - once one part uses options as it's decision making mechanism, all parts have to respond. But anyway, I agree - naked call options is a much more accurate term. But it is a difficult term for folks to get their heads around (incurring debt is something the post Marx Brothers world has gotten used to. Outside specialised areas of finance, not so much with Options)
- walshemj 12y ago
  Read Harpo's autography for an amusing story about how he covered off a huge margin call in the wall street crash by doing private gigs for some gangster mates of chico
  - lifeisstillgood 12y ago
    That's weird enough to be true ! I was thinking of the scene in A day at the Races, where the gangsters (the terrorists of the day) blocked the road with a car, and (Harpo?) on the escaped horse simply leaps and sails over it. Chico exclaims "Did you see that - the horse cleared the car !" Groucho - "well, I wish I could clear mine!" And 80 years ago we have the consumer debt crisis still writ large.
meesterdude 12y ago
While I agree with the overall message in this article, "unhedged call option" is not a phrase most people will get. "technical debt" is much easier to understand. "technical gambling" might be better, though i realize not as accurate as "call option". the term "technical debt" is fairly clear; "technical credit" or 'technical lending" is fuzzier but also more descriptive. Maybe the compromise is "technical debt with interest" actually, "technical trading" might be a good contender too. You might make out in the long run, or crash and burn. It's all about trade-offs anyway; not writing tests now means future you will have to write them. Sometimes this is fine, sometimes this is a truly horrible idea, and sometimes it could go either way.
- arthurjj 12y ago
  I agree with you that "unhedged call option" is not a phrase most people will get, on the other hand software engineering needs a better vocabulary around tech debt. There is a very specific type of tech debt that I think this describes So if you think we need better differentiation of technical debt (which I do) then finance is a good source of those differentiations[1] Personally I've heard tech debt used to describe everything from tightly coupled UI/DB code, to design decisions the person disagreed with, to code without tests. Even though those are obviously 3 different problems. So I'm for increasing the size of our vocabulary [1] I actually wrote a whole article using finance terms to think about tech debt. https://medium.com/@the_ajohnston/questions-about-the-debt-in-tech-debt-d651fa08980a https://medium.com/@the_ajohnston/questions-about-the-debt-i...
- briandear 12y ago
  Why does it matter that "most" people don't get it. If we call an array a hash, that might be a more well known term, yet if it's innaccurate, what difference does it make? It's the wrong term. Using the wrong term to describe something simply because the wrong term is more well known doesn't make it a better term to use. As I mentioned in another comment, it isn't the term itself that matters, what matters is the meaning. "Technical debt" is the wrong paradigm because of the simple fact that it doesn't always have to be repaid and in fact making that "investment" could result in a higher return if it doesn't have to be repaid. Of course, it could result in a much lower return if it has to be repaid. With debt, you have a known interest rate and upfront, you are aware of the future cost. However, with technical debt we never know the future cost; thus the debt analogy is completely innaccurate. And technical trading as a term is just completely wrong because the term technical trading already has a meaning; and it has nothing to do with understanding the unknown future benefit or gain. It has to do with making decisions (and predictions) based in extrapolating past results into the future. If anything we should be calling it fundamental trading since fundamental trading is making investment decisions based on a holistic view of the security in question. So, the decision to incur a technical "debt" is made with an understanding of the entire system and the cost-benefit analysis of paying "cash" now versus paying an unknown amount of cash later -- or not having to pay anything at all. One could call it gambling, but a more accurate description would be risk management. Using a risk management decision matrix one could say that the risk of someone dying in a flood at a shopping mall would be catastrophic, however the likelihood is exceptionally low, so it wouldn't make sense to have life boats spaced every 10 meters. However, it could happen, but the shopping mall owner chose to incur that "debt" of not having lifeboats because they determined that the cost wasn't justified given the profile of the risk. A debt analogy would say that a shopping mall absolutely will be flooded eventually and the debt would exist until such day that the owner bought lifeboats.
overgard 12y ago
The problem with the technical debt concept is that it implies there's this debt-free way of doing things. Like there's some sort of platonic form of "good" code that everything must aspire to, and good teams write code that doesn't have debt. What I've actually seen in practice is that "technical debt" mostly means "things I wouldn't have written that way." It has very little to do with the code and more to do with the philosophical leanings of the commenter.
- morgante 12y ago
  I disagree. I have willfully acquired technical debt on many occasions by writing code in a hacky way which, given more time, I wouldn't have chosen. Technical debt is a great metaphor for explaining this to non-tech stakeholders. They understand that choosing to rush a feature out now will lead to slower development (paying back the debt) later.
  - briandear 12y ago
    But to be fair, there's also the potential benefit of not having to pay that debt back. If the feature fails from a market perspective, you've actually saved money by incurring the debt. That's the whole concept behind the Lean Startup.
- ulisesrmzroche 12y ago
  In startups, technical debt by your definition has more to do with not having enough time/resources to spend on the problem. Code philosophy is the first thing that goes out the door.
- hw 12y ago
  Yes, there is such a thing as 'good code' that people should aspire to, or at least good practices when it comes to writing code. There are good teams that write code that has no or very little debt. It's also not just bad code that leads to technical debt, but bad decisions when it comes to code-related things like architecture, tech stack, which version of libraries / languages to use, etc.
- crdoconnor 12y ago
curiously 12y ago
This is such an excellent analogy and easy for me to understand as I am aware of how options work. Writing options is never a good act if it is naked (unlimited downside, limited profit). So what about buying a naked option (limited downside, unlimited profit) and what would that look like with code? A careful and well tested codebase to begin with that ends up paying off it's investment?
eCa 12y ago
Yeah, and if they worked for Lehman they're gonna love the unhedged call opinion. It's exciting.
grandalf 12y ago
Not all code debt contains massive downsides. The key to using technical debt wisely is understanding the difference, and architecting a system that is loosely coupled to allow strategic debt to be taken on in places where it makes sense.
- pm 12y ago
  Technical debt is an elegant analogy. However, I find the majority of systems on which I work are not loosely coupled. And yet, judging from the notes left by my antecedents, "loosely coupled" was the ideal for which they were striving. Is there a metric, or at least a heuristic, that can be applied in this situation?
  - grandalf 12y ago
    I think the key is for developers to understand coupling. There are lots of kinds of coupling. This book, is not specifically about coupling but the first chapter is an excellent overview that all developers should read: http://www.apress.com/9781590596432/ http://www.apress.com/9781590596432/
brudgers 12y ago
The article ignores the risk of avoiding technical debt, YNGNI, where the `it` you're not gonna' need is the implementation of some set of future-proof architectural features. Or as Knuth put it: Premature optimization is the root of all evil (or at least most of it) in programming. The problem of making something worth maintaining has priority...and the software upon which it depends is often a second or third order priority. Facebook was built on PHP. That using PHP created technical debt was a nice problem to have on the way to the bank. None of which is to say that writing bad software is ok. It is to say that bad software includes software that wastes time trying to anticipate and solve the wrong problems at the wrong time for the sake of an ideal rather than current business needs.
brandoncordell 12y ago
asdf
markbnj 12y ago
While I appreciate the interesting explanation of a naked call, I'm sorry to say that the category of good metaphors pretty much excludes any that require a lengthy exposition to understand.
vegabook 12y ago
The key idea behind the colloquial usage of the unhedged call option metaphor (or "writing naked calls") in financial circles, is the small chance of a catastrophic loss in return for a guaranteed small payout now. It is the idea of unfavourable non-linearity (asymmetry) in the reward/risk profile of a decision. It is mostly used pejoratively for any scenario which is superficially tempting but ultimately unattractive. I am not certain this is a good fit for the often reasonable decision to take shortcuts in software development, usually because the competitive landscape makes it very important to ship before competitors and land grab before others. Moreover, in a startup context, both metaphors break down: you can walk away from your technical debt by shutting down. You can't walk away from your financial debts (or call option shorts) so easily.
gfodor 12y ago
Mapping other basic option trades: Selling a naked put - Integrating a 3rd party library for a feature vs building it yourself. Immediate benefits, and probably unlikely to go sideways, but if the framework turns out to suck you suddenly incur a large unexpected body of pain. However, unlike a naked call, there's understood limited downside, limited to the functionality the library provides. Buying a put - Building in any kind of protection from "very low probability but high damage" events, such as provisioning a completely separate infrastructure in the case of a massive DC or network outage, or having a completely separate monitoring system in case the first goes down in the middle of fighting a separate fire. Buying a call - Basically anytime you make an engineering bet that costs a bit of time and is unlikely to pan out but if it does, you win big. Like a spike to try some state of the art algorithm or bringing on a short term consultant to solve a really hard problem. If your whole team is always doing these in the long run you lose, but strategically doing these when they make sense in the long run can result in huge gains. Selling a covered call - Focusing on consulting services vs building a product. Steady income, but in the unlikely case you build something that strikes gold, it won't be you who becomes rich overnight, it's the person who paid you to build it.
abathur 12y ago
I wish the dominant metaphors weren't so business-y--they end up framing the discussion in a way that we're stuck talking about what other business-y metaphors would be better. Explaining that doing things "bad" creates "technical debt" or "unhedged call options" I think sets us up for not being taken all that seriously because these things themselves are abstractions that we have to work hard to reason about effectively. Is it more useful if we say something tangible--that programming is like working on a house? Imagine you just started working on updating a house last month. The owner comes to you with a request that they be able to see what's going on in the kitchen from the living room; you _could_ just knock a hole in the wall. That would satisfy the basic requirements, but it's going to make a mess, it's going to look like shit, and it may disrupt the electricity/plumbing/hvac or even the stability of the house itself. But even if we make a proper window or door between the rooms without disrupting other systems in the house and clean up our mess, it's still possible we make a door or window that is a little different than all of the other doors and windows the past builders have put in the house. In 2 or 10 or 20 years, after several maintainers have come and gone, the owner discovers that they're being bled dry by the house's energy inefficiency. The new maintainer may go measure a window twice and get the dimensions down precisely and then count all of the windows in the house that look the same. Then they go place an order for N new energy-efficient windows. When the windows arrive and they're getting ready to replace them, they come to the terrifying realization that every window in the house is actually custom, and only a few of the windows will fit. They install the windows that fit and try to return the others only to find out the vendor charges a healthy restocking fee. Down 40% of our budget for replacing the windows but only having actually replaced 15% of them, we no longer have enough money to replace the rest. The owner decides to just use the remaining 60% to cover the increased energy costs instead of fixing the issues. The new maintainer goes to put the diagonal blinds back up on the windows that did get replaced and discovers the custom mounting hardware has gone missing in the shuffle, so the blinds get left in the corner with a note that someone needs to find a way to put them back up when there is time and money. It's the middle of the winter anyways; the sun is always under the horizon when the owners are home. Because this is a _funhouse_, these were of course the blinds with the greatest role in reflecting summer heat, and despite the improved window technology, total energy efficiency is going to be in the shitter come summertime. For now, perhaps quixotically, energy efficiency is buoyed by the extra solar heat; the owner seems happy enough with the updates, and the metrics all show good performance. Houses need maintenance. Things on or in them break and can't be fixed because either the parts aren't made that way anymore or the knowledge of how to fix it has eroded. They end up with empty telephone nooks and doors that were sheet-rocked over instead of being removed. A major appliance stops working and you discover the house needs infrastructure updates before a contemporary version of the same can be installed. The maintainers want to add a floor and some new rooms and they need an architect and an engineer to make sure they aren't going to ruin the roof line, slab or overload a wall. Down the road it will have different rooms built in the fashion of three decades over a span of 80 years. Further down the road a room will get sealed off when the roof caves in and the owner doesn't have the funds to fix it.
michaelochurch 12y ago
Bad code is only one kind of "technical debt" and it's the worst kind. Technical debt could also be choosing not to add a feature. If you document the shortfall (say, your system won't scale beyond a single-node database, because you aren't going to need that for at least a year) and why it is there, you can mitigate the damage and make it possible for future users and maintainers to figure out what's going on. Code quality problems are, as expressed in the OP, an unknown unknown. It's rare that anyone has a handle on just how bad things are, until it's too late. Also, there are sociological issues with legacy rescue projects that businesspeople, who'd rather think of programmers as fairly interchangeable, don't like to contend with: maintenance is only effective if done by high-quality programmers, but it's expensive and often hard as hell to motivate good people to do it. A pat on the back and a 10% bonus won't do it, because it doesn't come close to offsetting the career costs of doing undesirable work. There is an apocryphal story about a trader buying chocolate santa futures and forgetting to sell them on. Eventually a truckload turned up at the Wall Street headquarters. This has little to do with the subject itself, but this has actually happened, sort-of. Futures contracts usually don't include Wall Street as a delivery location, so it's not like the trader ends up taking physical delivery at the workplace. The contract will specify where one must make or take delivery, and most delivery locations are in the Midwest or Plains. When a trader fucks up and has to make or take delivery, there are services that handle it, but it's expensive. If you get stuck taking delivery of, say, $500,000 worth of butter, you'll probably have to pay the agency 50 cents on the dollar, or $250,000, to handle the task of getting your surplus butter to a wholesaler. It hurts pretty bad.
- artmageddon 12y ago
  > A pat on the back and a 10% bonus won't do it, because it doesn't come close to offsetting the career costs of doing undesirable work. This pretty much describes what I've been enduring for the past year, especially since we only get (adjusted for profits + performance) 10% bonuses.
snarfy 12y ago
I still like shoddy construction/shanty village as an analogy. People know what it is and it is tangible unlike debt or any other financial reference. You can build a shanty village without a plan that supports a million people, but the first fire, storm, earthquake, etc destroys the whole thing. Also, for some reason when Bob flushes his toilet, the power goes out briefly in the capitol building. Nobody knows why, but routing power through the sewer last sprint to save time probably wasn't a good idea.
- tboyd47 12y ago
  Seconded. The point is not that bad code is a necessary evil (it's really not), but that they are going to end up with it if they insist on doing things a certain way. Another good one is, "Well, I can build you a 20,000-foot fire-breathing chicken made of balsamwood, if that's what you want, or if you just want me to parse a CSV file, I can do that too." As a developer who has to hear the "tech debt" thing all the time from my co-workers, I really hate that concept. Metaphorically or otherwise, I don't like being in the position of a bank demanding high interest payments from a poor sap who didn't realize what he was getting into. That's not how I view myself in relation to my employers and clients.
bbcbasic 12y ago
Real debt has to be paid back. There is no requirement to ever pay down the technical debt. Therefore the analogy is misleading. I also think that the call option is a bad analogy for similar reasons. In a call option you could be obliged to pay out. You never have to pay out with code. You can decide to get your developers to write code or not write code. No bailiffs will come knocking on the door. Technical drag coefficient may be a better analogy. For a car, the drag force increases as you speed increases. For code, the more features you want to add, bug you want to fix, etc. (i.e. the bigger your velocity) the more the TDC will kick in to slow you down. It may put a speed limit entirely on what you can do until you put work in to reduce it. Also you can write-off the car and invest in a new one. I have seen this many times of course - the 'new product' that is written that won't have all of the problems of the last one.
- shitloadofbooks 12y ago
  Real debt doesn't have to be paid down though. Eventually it compounds too far and the person/entity can't even meet the interest payments and goes bankrupt. There's plenty of analogies that can be made with technical debt. To really stretch the analogy, those same people often then end up in (technical) debt again a few years later when they repeat the same mistakes.
  - bbcbasic 12y ago
    Bad code is kind-of analogous to debt, but not perfectly. Hence the confusion. In some ways it is worse than real debt - the compound interest rate is atrocious. Like a loan shark. But in some ways it is not as bad - you never are required by another party to pay back the debt. If you stop making money from the product, the debt is cancelled to $0. Real debt has to be paid down, unless there is collateral, but even then most lenders want to know when and how they are getting their money back.
    - dbdr 12y ago
      Suppose an opportunity comes up, but the technical debt in your software makes it exceedingly hard to respond to it. Either you still respond to it (with an obvious high cost), or you let the opportunity pass (and you "pay" the opportunity cost). So in a sense you can be forced to pay back your technical debt, if you include the "cost" of missed opportunities. But you are right that you always have the choice between those two, unlike real debt. http://en.wikipedia.org/wiki/Opportunity_cost http://en.wikipedia.org/wiki/Opportunity_cost
BenLinders 12y ago
Want to know what Steve Freeman and Chris Matts have to say about call options or technical debt? Read http://www.infoq.com/news/2014/12/call-options-bad-code http://www.infoq.com/news/2014/12/call-options-bad-code

220 points by yummyfajitas 12y ago

pavlov 12y ago

Maybe metaphors are like short-selling: unlimited future downside in exchange for potential quick gains.

jerguismi 12y ago
Unlimited future downside? Really? I would like to know on which context this is possible. I don't know in which context the writer is writing, I'm a developer and have been mostly working on startup-style projects. If you fail, you don't make a buck, the product does not work or does not sell. The downside is the lost time and money. I have also known couple of startups, which have had really good engineers who have invested lots to testing, maintainability etc. In the end however the business hasn't succeeded selling the product, and all that investment was worth essentially nothing.
- pavlov 12y ago
  I was trying to make an ironic joke about the pitfalls of metaphors by using a metaphor. It didn't really have anything to do with the premise of the origīnal post. So I apologize for being off-topic - the opportunity was just too tempting :)
  - jdp23 12y ago
    And the response was a great illustration of your point. Nice self-documenting experiment :)
  - nightpool 12y ago
    Actually, I think the commentator here assumed (as I did) that you were slightly off-topic talking about the use of metaphors in software programming. I feel a little bit silly now, FWIW.
- Dewie 12y ago
  > Unlimited future downside? Really? I would like to know on which context this is possible. Don't take it so literally; it's just a short-selling simile.
  - deleted 12y ago
    [deleted]
- e28eta 12y ago
  How about a product that kills people: Therac-25, any other prominent examples of failures? Or destroys the users' financial well-being: software they use to run their small business, or invest their retirement?
  - deleted 12y ago
    [deleted]
  - Snail_Commando 12y ago
    http://www.fas.org/spp/starwars/gao/im92026.htm http://www.fas.org/spp/starwars/gao/im92026.htm https://en.wikipedia.org/wiki/MIM-104_Patriot#Failure_at_Dhahran https://en.wikipedia.org/wiki/MIM-104_Patriot#Failure_at_Dha... Whether or not this can be attributed to technical debt, I don't know. But it is an instance of a software failure that resulted in death.
- abofh 12y ago
  There's also no unlimited downside in finance -- eventually you can't take out more debt, can't pay the interest, and default (creating counter party risk). I suppose net across the system, you could inflict more downside to others exposed to your default, but it's not unlimited unless you can wipe out the entire planetary economy (financial and non financial) with your bet.
fiatmoney 12y ago
In the normal case of short selling (absent a large enough position to be subject to a short squeeze) future downside is not unlimited; your broker will close your position unless you put up enough capital.
bbcbasic 12y ago
Metaphors spread confusion by taking something that is simple to understand, and translating it to another domain so that people get the wrong idea. A bit like learning to fish is better than giving a guy a fish.

dropit_sphere 12y ago

This is actually a worthy terminology switch, capturing the uncertainty of software development.

jerguismi 12y ago

"Debt is predictable and can be managed, it’s just another tool." Well, not really. For example, if you took usd-based debt in russia, you are now quite royally fucked.

samstokes 12y ago
That's not (only) debt, that's (also) currency speculation.
- jacques_chester 12y ago
  So it'd be extending the analogy to bet on untested new technologies.
cmdkeen 12y ago
It's actually a really good example of the article - there's nothing wrong with debt denominated in a foreign currency, you can hedge against the currency risk. The whole thing is about risk, if you hedge away all your risk financially there is generally no profit to be made (you're left with arbitrage), if you hedge away all your technical debt then you've essentially (re)implemented it properly.

fcbrooklyn 12y ago

Technical debt is actually a really good analogy, precisely because non-technical finance people understand the tradeoff pretty intuitively. Sometimes incurring debt is the right thing to do, but you'll want to pay it down or you'll have to live with the interest. This is true of both monetary and technical debt. For extra credit, you might assign notional interest rates to your technical debt... if they're in the double digits I promise you they'll scare the finance guy.

majc2 12y ago
If you want to scare them talk about it being a technical credit card - pay that debt back regularly and try and clear it as quickly as you can.
- lumpypua 12y ago
  Ehhh, the analogy doesn't hold totally because you might not have to pay it back. In that case you're ahead. FTA: Call options are a better model than debt for cruddy code (without tests) because they capture the unpredictability of what we do. If I slap in an a feature without cleaning up then I get the benefit immediately, I collect the premium. If I never see that code again, then I’m ahead and, in retrospect, it would have been foolish to have spent time cleaning it up.
  - fcbrooklyn 12y ago
    I agree, the analogy is imperfect, because you don't pay interest unless you need to extend or maintain the code. It's only useful in a world where the codebase in question is under ongoing development, but those are the situations where I've used it. Naked calls work fine as an analogy in the case you describe.
  - briandear 12y ago
    That's the home run point: you might not have to pay it back. That is exactly why the debt or credit card analogy doesn't hold. An uncovered call is exactly the correct metaphor. This isn't even high finance we're talking about, this is fundamental options stuff. I'm not sure I understand the resistance to using the uncovered call terminology as opposed to the highly innaccurate (but more Main Street comprehensible) "debt" analogy. Debt (aside from bankruptcy ALWAYS has to be repaid. Yet we all know that technical debt doesn't always have to be repaid. Debt is a terribly imprecise way of thinking about it.

angersock 12y ago

God, I want to short my codebase so hard. What would the engineering equivalent of that be, I wonder? Quitting and getting hired back as a consultant?

nostromo 12y ago
Just sell a company and codebase you've yet to create. If the market value seems greater before you've actually shipped: congrats, you just made money shorting your own company.
mbesto 12y ago
> God, I want to short my codebase so hard. Invest in your competitor.
- bryanh 12y ago
  If quality of code had a causal relation with success - that might be accurate. I'm not sure it does.
  - the_cat_kittles 12y ago
    i was going to write that good code is a necessary but not sufficient condition. but thats not true either!
    - deleted 12y ago
      [deleted]
    - chii 12y ago
      success of the business and good quality code does have a relation ship - it's just not an obvious one. Like reversing a car with a trailer, the direction you want to go can be difficult to control, but it doesn't mean your driving doesn't affect it.
curiously 12y ago
borrow money and hire an expert contractor and fire them and claim the credit and reap the rewards.

mattvanhorn 12y ago

I worked at a place where the VPE would talk about technical debt as a mortgage. Yet they had a culture that abhorred paying down the debt through refactoring, and so it was more like one of those interest-only payment mortgages. They paid higher interest in the form of reduced productivity and speed, and ended up with the same amount of debt as when they started.

radiowave 12y ago

I've always liked this analogy in preference to the standard notion of debt, but if we find ourselves having to explain the analogy, is it such a good analogy in the first place? So I think it needs to be judged in context - who are we trying to communicate with?

gojomo 12y ago

There's something to this – the emphasis on the optionality of 'technical debt' – but it's not quite 'unhedged'. There's not an 'unlimited downside', as there can be when writing a call on an asset that could appreciate boundlessly. With tech projects there's almost always a de facto "abandon" option – if not for the firm then at least for the individual engineers. So whenever the cost of proceeding is higher than the expected value, you exit. That clips the downside, more like some sort of combined option position. Or more like a specific kind of debt: nonrecourse loans secured by collateral. You get the money up front, but if it proves impossible to repay, you simply surrender the collateral. In this case, the collateral is the project itself: either the option to continue, or the IP rights, or the enclosing firm. And, in the event of failure, those may be worth nothing, so you aren't losing an unbounded amount. For monetary debt, these fragmentary artifacts may in fact be surrendered to the creditors. In the case of metaphorical technical debt, you surrender up those hopes and dreams and mental (sunk) costs, to the reality that there won't ever be the time and budget to fix the system. And so this leads to a different conclusion than the article, which ends with a near-religious stance against the inflexible evil of debt. Because the downside – project abandonment – is capped, sometimes technical debt is worth taking on, when acceleration-to-market (and thus market-feedback-learning) is of paramount importance. You're borrowing from the future, but you only pay it back (with interest) if there's wild success. If you fail for any other reason – perhaps things having nothing to do with the technical debt – you don't have to pay it off, you just surrender the (essentially worthless) collateral. That's a hard thing for people with an aesthetic or craftsperson mentality to accept. And it still sucks when it's the technical debt itself – the cost of fixing old rushed choices – that occasionally makes a project no longer competitively viable. Your monetary credit report is unblemished, but your self-conception can take a hit.

ThisIBereave 12y ago

Maybe this works for people in finance, but I can't see it being useful otherwise. The concept you're using as an analogy just isn't widely known.

sitharus 12y ago
I'd agree, but the people we have to justify spending refactoring time to are often in finance.
- morgante 12y ago
  I don't know about that. Unless you're explicitly a FinTech company, most of the business folks aren't necessarily well-versed in options markets.
curiously 12y ago
I totally understand this pain point before I began reading on options I was clueless, mystified but ultimately realized options are akin to trading stocks (buying low selling high) but with the added time restriction and ability to make money in any market. Options are tricky to understand but essentially, think of it as just a piece of paper or a contract between you and the person buying it from you. It's a buy/sell market that exists on these "papers". Options trading essentially revolve around buying these papers which usually have an expiry date of between weeks to years and at what price you can buy the underlying good before the expiry date. The profit is made from the valuation of this paper going up and down based on the underlying value of what this paper represents. The paper can be contract about beef, corn, oil and share price of Apple. Just like the stock market, you want to pay cheap price for a paper and sell it when it goes high, but the beauty of options is since you don't actually trade the actual good itself, you can create a dizzying array of strategies and combinations to make money in any type of situation, but with the condition that you have to be right about what market we are in (trending up, down, sidways, volatility etc). Writing an option is like selling a piece of paper that says the person buying your paper will have the ability to buy the stock at the price written on the paper. If the price is low and the stock price goes up, well you now have to buy X number of shares that was written on the paper at the high price to give to this guy, causing great deal of loss to you (since you sold the paper for some cash earlier). If the stock price falls, then you could buy the shares at the low low price using the money you made from selling the paper and give it to the other guy, who most likely won't ask you to do this and just think about the time he paid you to write him a piece of paper that is now "expired" or worthless.

dinkumthinkum 12y ago

I don't like this kind of discussion. I don't believe technical debt is a thing and I think this idea if technical debt as really straining the metaphor. This is like bike shedding.

deleted 12y ago
[deleted]
jhull 12y ago
What do you consider technical debt to be then? Just bad code?
- briandear 12y ago
  Code (or system design) that has potential issues that may or may not need to be resolved in the future, but the benefit of not doing it now outweighs the pain of doing it later.
  - jhull 12y ago
    Right. I know what technical debt is. The commenter I replied to said "I don't believe technical debt is a thing" and was hoping (s)he would elaborate.

dragonwriter 12y ago

It may be a more accurate analogy, but its a less useful metaphor for most audiences. Most people have a useful intuition about debt that the "technical debt" metaphor leverages. Comparatively very few people have a useful intuition about "unhedged call options" that using it as a metaphor for poor code quality would leverage. Also, I think predictable ongoing support cost is a big result of poor code quality in production systems, so that aspect of the debt metaphor isn't completely off-base (there are also unpredictable potential costs in the future, as well, so its not a perfect analogy.)

lifeisstillgood 12y ago

I keep bumping into the notion of options in software development - there are (and I will try to hunt them down) a couple of well known papers on option pricing different features. It is interesting because if applied it would spread through the whole organisation using it - once one part uses options as it's decision making mechanism, all parts have to respond. But anyway, I agree - naked call options is a much more accurate term. But it is a difficult term for folks to get their heads around (incurring debt is something the post Marx Brothers world has gotten used to. Outside specialised areas of finance, not so much with Options)

walshemj 12y ago
Read Harpo's autography for an amusing story about how he covered off a huge margin call in the wall street crash by doing private gigs for some gangster mates of chico
- lifeisstillgood 12y ago
  That's weird enough to be true ! I was thinking of the scene in A day at the Races, where the gangsters (the terrorists of the day) blocked the road with a car, and (Harpo?) on the escaped horse simply leaps and sails over it. Chico exclaims "Did you see that - the horse cleared the car !" Groucho - "well, I wish I could clear mine!" And 80 years ago we have the consumer debt crisis still writ large.

meesterdude 12y ago

While I agree with the overall message in this article, "unhedged call option" is not a phrase most people will get. "technical debt" is much easier to understand. "technical gambling" might be better, though i realize not as accurate as "call option". the term "technical debt" is fairly clear; "technical credit" or 'technical lending" is fuzzier but also more descriptive. Maybe the compromise is "technical debt with interest" actually, "technical trading" might be a good contender too. You might make out in the long run, or crash and burn. It's all about trade-offs anyway; not writing tests now means future you will have to write them. Sometimes this is fine, sometimes this is a truly horrible idea, and sometimes it could go either way.

arthurjj 12y ago
I agree with you that "unhedged call option" is not a phrase most people will get, on the other hand software engineering needs a better vocabulary around tech debt. There is a very specific type of tech debt that I think this describes So if you think we need better differentiation of technical debt (which I do) then finance is a good source of those differentiations[1] Personally I've heard tech debt used to describe everything from tightly coupled UI/DB code, to design decisions the person disagreed with, to code without tests. Even though those are obviously 3 different problems. So I'm for increasing the size of our vocabulary [1] I actually wrote a whole article using finance terms to think about tech debt. https://medium.com/@the_ajohnston/questions-about-the-debt-in-tech-debt-d651fa08980a https://medium.com/@the_ajohnston/questions-about-the-debt-i...
briandear 12y ago
Why does it matter that "most" people don't get it. If we call an array a hash, that might be a more well known term, yet if it's innaccurate, what difference does it make? It's the wrong term. Using the wrong term to describe something simply because the wrong term is more well known doesn't make it a better term to use. As I mentioned in another comment, it isn't the term itself that matters, what matters is the meaning. "Technical debt" is the wrong paradigm because of the simple fact that it doesn't always have to be repaid and in fact making that "investment" could result in a higher return if it doesn't have to be repaid. Of course, it could result in a much lower return if it has to be repaid. With debt, you have a known interest rate and upfront, you are aware of the future cost. However, with technical debt we never know the future cost; thus the debt analogy is completely innaccurate. And technical trading as a term is just completely wrong because the term technical trading already has a meaning; and it has nothing to do with understanding the unknown future benefit or gain. It has to do with making decisions (and predictions) based in extrapolating past results into the future. If anything we should be calling it fundamental trading since fundamental trading is making investment decisions based on a holistic view of the security in question. So, the decision to incur a technical "debt" is made with an understanding of the entire system and the cost-benefit analysis of paying "cash" now versus paying an unknown amount of cash later -- or not having to pay anything at all. One could call it gambling, but a more accurate description would be risk management. Using a risk management decision matrix one could say that the risk of someone dying in a flood at a shopping mall would be catastrophic, however the likelihood is exceptionally low, so it wouldn't make sense to have life boats spaced every 10 meters. However, it could happen, but the shopping mall owner chose to incur that "debt" of not having lifeboats because they determined that the cost wasn't justified given the profile of the risk. A debt analogy would say that a shopping mall absolutely will be flooded eventually and the debt would exist until such day that the owner bought lifeboats.

overgard 12y ago

The problem with the technical debt concept is that it implies there's this debt-free way of doing things. Like there's some sort of platonic form of "good" code that everything must aspire to, and good teams write code that doesn't have debt. What I've actually seen in practice is that "technical debt" mostly means "things I wouldn't have written that way." It has very little to do with the code and more to do with the philosophical leanings of the commenter.

morgante 12y ago
I disagree. I have willfully acquired technical debt on many occasions by writing code in a hacky way which, given more time, I wouldn't have chosen. Technical debt is a great metaphor for explaining this to non-tech stakeholders. They understand that choosing to rush a feature out now will lead to slower development (paying back the debt) later.
- briandear 12y ago
  But to be fair, there's also the potential benefit of not having to pay that debt back. If the feature fails from a market perspective, you've actually saved money by incurring the debt. That's the whole concept behind the Lean Startup.
ulisesrmzroche 12y ago
In startups, technical debt by your definition has more to do with not having enough time/resources to spend on the problem. Code philosophy is the first thing that goes out the door.
hw 12y ago
Yes, there is such a thing as 'good code' that people should aspire to, or at least good practices when it comes to writing code. There are good teams that write code that has no or very little debt. It's also not just bad code that leads to technical debt, but bad decisions when it comes to code-related things like architecture, tech stack, which version of libraries / languages to use, etc.
crdoconnor 12y ago

curiously 12y ago

This is such an excellent analogy and easy for me to understand as I am aware of how options work. Writing options is never a good act if it is naked (unlimited downside, limited profit). So what about buying a naked option (limited downside, unlimited profit) and what would that look like with code? A careful and well tested codebase to begin with that ends up paying off it's investment?

eCa 12y ago

Yeah, and if they worked for Lehman they're gonna love the unhedged call opinion. It's exciting.

grandalf 12y ago

Not all code debt contains massive downsides. The key to using technical debt wisely is understanding the difference, and architecting a system that is loosely coupled to allow strategic debt to be taken on in places where it makes sense.

pm 12y ago
Technical debt is an elegant analogy. However, I find the majority of systems on which I work are not loosely coupled. And yet, judging from the notes left by my antecedents, "loosely coupled" was the ideal for which they were striving. Is there a metric, or at least a heuristic, that can be applied in this situation?
- grandalf 12y ago
  I think the key is for developers to understand coupling. There are lots of kinds of coupling. This book, is not specifically about coupling but the first chapter is an excellent overview that all developers should read: http://www.apress.com/9781590596432/ http://www.apress.com/9781590596432/

brudgers 12y ago

The article ignores the risk of avoiding technical debt, YNGNI, where the `it` you're not gonna' need is the implementation of some set of future-proof architectural features. Or as Knuth put it: Premature optimization is the root of all evil (or at least most of it) in programming. The problem of making something worth maintaining has priority...and the software upon which it depends is often a second or third order priority. Facebook was built on PHP. That using PHP created technical debt was a nice problem to have on the way to the bank. None of which is to say that writing bad software is ok. It is to say that bad software includes software that wastes time trying to anticipate and solve the wrong problems at the wrong time for the sake of an ideal rather than current business needs.

brandoncordell 12y ago

asdf

markbnj 12y ago

While I appreciate the interesting explanation of a naked call, I'm sorry to say that the category of good metaphors pretty much excludes any that require a lengthy exposition to understand.

vegabook 12y ago

The key idea behind the colloquial usage of the unhedged call option metaphor (or "writing naked calls") in financial circles, is the small chance of a catastrophic loss in return for a guaranteed small payout now. It is the idea of unfavourable non-linearity (asymmetry) in the reward/risk profile of a decision. It is mostly used pejoratively for any scenario which is superficially tempting but ultimately unattractive. I am not certain this is a good fit for the often reasonable decision to take shortcuts in software development, usually because the competitive landscape makes it very important to ship before competitors and land grab before others. Moreover, in a startup context, both metaphors break down: you can walk away from your technical debt by shutting down. You can't walk away from your financial debts (or call option shorts) so easily.

gfodor 12y ago

Mapping other basic option trades: Selling a naked put - Integrating a 3rd party library for a feature vs building it yourself. Immediate benefits, and probably unlikely to go sideways, but if the framework turns out to suck you suddenly incur a large unexpected body of pain. However, unlike a naked call, there's understood limited downside, limited to the functionality the library provides. Buying a put - Building in any kind of protection from "very low probability but high damage" events, such as provisioning a completely separate infrastructure in the case of a massive DC or network outage, or having a completely separate monitoring system in case the first goes down in the middle of fighting a separate fire. Buying a call - Basically anytime you make an engineering bet that costs a bit of time and is unlikely to pan out but if it does, you win big. Like a spike to try some state of the art algorithm or bringing on a short term consultant to solve a really hard problem. If your whole team is always doing these in the long run you lose, but strategically doing these when they make sense in the long run can result in huge gains. Selling a covered call - Focusing on consulting services vs building a product. Steady income, but in the unlikely case you build something that strikes gold, it won't be you who becomes rich overnight, it's the person who paid you to build it.

abathur 12y ago

I wish the dominant metaphors weren't so business-y--they end up framing the discussion in a way that we're stuck talking about what other business-y metaphors would be better. Explaining that doing things "bad" creates "technical debt" or "unhedged call options" I think sets us up for not being taken all that seriously because these things themselves are abstractions that we have to work hard to reason about effectively. Is it more useful if we say something tangible--that programming is like working on a house? Imagine you just started working on updating a house last month. The owner comes to you with a request that they be able to see what's going on in the kitchen from the living room; you _could_ just knock a hole in the wall. That would satisfy the basic requirements, but it's going to make a mess, it's going to look like shit, and it may disrupt the electricity/plumbing/hvac or even the stability of the house itself. But even if we make a proper window or door between the rooms without disrupting other systems in the house and clean up our mess, it's still possible we make a door or window that is a little different than all of the other doors and windows the past builders have put in the house. In 2 or 10 or 20 years, after several maintainers have come and gone, the owner discovers that they're being bled dry by the house's energy inefficiency. The new maintainer may go measure a window twice and get the dimensions down precisely and then count all of the windows in the house that look the same. Then they go place an order for N new energy-efficient windows. When the windows arrive and they're getting ready to replace them, they come to the terrifying realization that every window in the house is actually custom, and only a few of the windows will fit. They install the windows that fit and try to return the others only to find out the vendor charges a healthy restocking fee. Down 40% of our budget for replacing the windows but only having actually replaced 15% of them, we no longer have enough money to replace the rest. The owner decides to just use the remaining 60% to cover the increased energy costs instead of fixing the issues. The new maintainer goes to put the diagonal blinds back up on the windows that did get replaced and discovers the custom mounting hardware has gone missing in the shuffle, so the blinds get left in the corner with a note that someone needs to find a way to put them back up when there is time and money. It's the middle of the winter anyways; the sun is always under the horizon when the owners are home. Because this is a _funhouse_, these were of course the blinds with the greatest role in reflecting summer heat, and despite the improved window technology, total energy efficiency is going to be in the shitter come summertime. For now, perhaps quixotically, energy efficiency is buoyed by the extra solar heat; the owner seems happy enough with the updates, and the metrics all show good performance. Houses need maintenance. Things on or in them break and can't be fixed because either the parts aren't made that way anymore or the knowledge of how to fix it has eroded. They end up with empty telephone nooks and doors that were sheet-rocked over instead of being removed. A major appliance stops working and you discover the house needs infrastructure updates before a contemporary version of the same can be installed. The maintainers want to add a floor and some new rooms and they need an architect and an engineer to make sure they aren't going to ruin the roof line, slab or overload a wall. Down the road it will have different rooms built in the fashion of three decades over a span of 80 years. Further down the road a room will get sealed off when the roof caves in and the owner doesn't have the funds to fix it.

michaelochurch 12y ago

Bad code is only one kind of "technical debt" and it's the worst kind. Technical debt could also be choosing not to add a feature. If you document the shortfall (say, your system won't scale beyond a single-node database, because you aren't going to need that for at least a year) and why it is there, you can mitigate the damage and make it possible for future users and maintainers to figure out what's going on. Code quality problems are, as expressed in the OP, an unknown unknown. It's rare that anyone has a handle on just how bad things are, until it's too late. Also, there are sociological issues with legacy rescue projects that businesspeople, who'd rather think of programmers as fairly interchangeable, don't like to contend with: maintenance is only effective if done by high-quality programmers, but it's expensive and often hard as hell to motivate good people to do it. A pat on the back and a 10% bonus won't do it, because it doesn't come close to offsetting the career costs of doing undesirable work. There is an apocryphal story about a trader buying chocolate santa futures and forgetting to sell them on. Eventually a truckload turned up at the Wall Street headquarters. This has little to do with the subject itself, but this has actually happened, sort-of. Futures contracts usually don't include Wall Street as a delivery location, so it's not like the trader ends up taking physical delivery at the workplace. The contract will specify where one must make or take delivery, and most delivery locations are in the Midwest or Plains. When a trader fucks up and has to make or take delivery, there are services that handle it, but it's expensive. If you get stuck taking delivery of, say, $500,000 worth of butter, you'll probably have to pay the agency 50 cents on the dollar, or $250,000, to handle the task of getting your surplus butter to a wholesaler. It hurts pretty bad.

artmageddon 12y ago
> A pat on the back and a 10% bonus won't do it, because it doesn't come close to offsetting the career costs of doing undesirable work. This pretty much describes what I've been enduring for the past year, especially since we only get (adjusted for profits + performance) 10% bonuses.

snarfy 12y ago

I still like shoddy construction/shanty village as an analogy. People know what it is and it is tangible unlike debt or any other financial reference. You can build a shanty village without a plan that supports a million people, but the first fire, storm, earthquake, etc destroys the whole thing. Also, for some reason when Bob flushes his toilet, the power goes out briefly in the capitol building. Nobody knows why, but routing power through the sewer last sprint to save time probably wasn't a good idea.

tboyd47 12y ago
Seconded. The point is not that bad code is a necessary evil (it's really not), but that they are going to end up with it if they insist on doing things a certain way. Another good one is, "Well, I can build you a 20,000-foot fire-breathing chicken made of balsamwood, if that's what you want, or if you just want me to parse a CSV file, I can do that too." As a developer who has to hear the "tech debt" thing all the time from my co-workers, I really hate that concept. Metaphorically or otherwise, I don't like being in the position of a bank demanding high interest payments from a poor sap who didn't realize what he was getting into. That's not how I view myself in relation to my employers and clients.

bbcbasic 12y ago

Real debt has to be paid back. There is no requirement to ever pay down the technical debt. Therefore the analogy is misleading. I also think that the call option is a bad analogy for similar reasons. In a call option you could be obliged to pay out. You never have to pay out with code. You can decide to get your developers to write code or not write code. No bailiffs will come knocking on the door. Technical drag coefficient may be a better analogy. For a car, the drag force increases as you speed increases. For code, the more features you want to add, bug you want to fix, etc. (i.e. the bigger your velocity) the more the TDC will kick in to slow you down. It may put a speed limit entirely on what you can do until you put work in to reduce it. Also you can write-off the car and invest in a new one. I have seen this many times of course - the 'new product' that is written that won't have all of the problems of the last one.

shitloadofbooks 12y ago
Real debt doesn't have to be paid down though. Eventually it compounds too far and the person/entity can't even meet the interest payments and goes bankrupt. There's plenty of analogies that can be made with technical debt. To really stretch the analogy, those same people often then end up in (technical) debt again a few years later when they repeat the same mistakes.
- bbcbasic 12y ago
  Bad code is kind-of analogous to debt, but not perfectly. Hence the confusion. In some ways it is worse than real debt - the compound interest rate is atrocious. Like a loan shark. But in some ways it is not as bad - you never are required by another party to pay back the debt. If you stop making money from the product, the debt is cancelled to $0. Real debt has to be paid down, unless there is collateral, but even then most lenders want to know when and how they are getting their money back.
  - dbdr 12y ago
    Suppose an opportunity comes up, but the technical debt in your software makes it exceedingly hard to respond to it. Either you still respond to it (with an obvious high cost), or you let the opportunity pass (and you "pay" the opportunity cost). So in a sense you can be forced to pay back your technical debt, if you include the "cost" of missed opportunities. But you are right that you always have the choice between those two, unlike real debt. http://en.wikipedia.org/wiki/Opportunity_cost http://en.wikipedia.org/wiki/Opportunity_cost

BenLinders 12y ago

Want to know what Steve Freeman and Chris Matts have to say about call options or technical debt? Read http://www.infoq.com/news/2014/12/call-options-bad-code http://www.infoq.com/news/2014/12/call-options-bad-code