Debt – My First Thirty Years

I still owe our readers an editorial, and know I have accumulated a huge debt over the last several years. Fortunately, you don’t seem to be charging me interest, so there is hope. As soon as you charge interest on a debt, it is possible for the debt to keep growing and become impossible to pay back. Charging interest, or at least excessive interest, is sometimes referred to as usury. Anyone taking advantage like this is sometimes called a loan shark. By lending money to someone who is desperate, needing food or a way to pay rent, or similar, and then threatening them with violence if they don’t repay causes debt, and despair, to spiral out of control. Not a good place to be.

What’s this got to do with programming, you may ask? Almost nothing, in one sense. And yet, tech debt is a term that gets banded around, so perhaps it’s got everything to do with programming. Why do we describe confusing, hard to maintain code as debt? We haven’t borrowed money to cover it, so can’t be charged interest. We may have cut a corner or two, in order to get something out the door quickly, leaving a problem to deal with later. I say later, but it often turns out to be sooner. With untested edge cases, things may blow up regularly. Without useful logging, you can’t figure out what happened. If the so-called quick win, cut corner, or tech debt, means people have to down tools and fix things on a regular basis, you have in fact slowed everything down. Cutting corners is very different to being in debt. Such short cuts are more like being in danger.

I recently described cutting corners as being like a Koch snowflake [Wikipedia-1]. Now, to build this ‘snowflake’, you start with a triangle and cut out the middle of each side replacing it with a smaller triangle, and continue ad infinitum. This, in some sense, is the opposite of cutting corners, since you add more corners each time, and tend towards something 8/5 times the original area. Cutting corners in code does often involve slapping extra bits in, copying and pasting code, wedging in a few booleans and if/else code paths and the like. Such short cuts are more like spare parts gaffer-taped on. Now, cutting corners comes from the idea of trespassing across a farmer’s field, or driving on the wrong side of the road at a bend, rather than sticking to the legal route. You could suggest illegal practices aren’t necessarily wrong and there are some perfectly legal cases where cutting corners makes life easier. If you smoke roll-ups, cigarette papers with the corners cut are much easier to roll – letting you tuck the paper in more easily. Or more seasonally, wrapping presents is something of an art form. I recall my Father telling me once about some way to calculate the smallest amount of wrapping paper needed, and claiming some chocolate bar manufacturers had saved a fortune using a similar idea. I was too young to pay much attention at the time and can’t recall the details now, but it involved cutting corners. Computer graphics also cut corners, tending to rely on representations made from a mesh of triangles, going in straight lines rather than curves. This also means you can do the mathematics once for several vertices and speed things up [Wikipedia-2]. Cutting corners can be a good thing or a bad thing; it depends.

In contrast, cutting the mustard is always good. When mustard was grown as a main crop, it “was cut by hand with scythes, in the same way as corn. The crop could grow up to six feet high and this was very arduous work, requiring extremely sharp tools. When blunt they ‘would not cut the mustard’” [Guardian]. Maybe tech debt is like blunt tools? By leaving behind software that’s hard to use or difficult to understand or change you’ve made life difficult. Even a skilled coder won’t be able to be very effective if armed with a blunt scythe.

Describing a dangerous or confusing system as debt seems odd. We decided to get some new lighting in our house and the electrician ran a safety test first. We were half expecting a can of worms, or some kind of spaghetti wiring situation. Hooray for a way to test things before touching anything live. I am pleased to report the house doesn’t need re-wiring and the electrician’s insulated snips worked but we need to have some ‘tech debt’ fixed before it is safe to get new lights installed. Without going into too many details, let’s say words like ‘Why would anyone do this?’ and ‘That’s very confusing!’ and ‘Why would anyone connect the earth wire to live?’ were banded about. Similar statements can end up as tech debt Jiras, and the engineers being told the customer’s priority is new lights, so these debt tickets will have to wait until later. As a customer, I want it to be safe to change a light bulb, so please fix the dangerous stuff first. Just saying. Letting engineers talk directly to customers is often the best way. There are conventions for which coloured wire connects where for reasons: to make the wiring safe for people to change, replace and extend in the future without a huge wiring diagram and user manual. Describing cutting corners and brazenly ignoring conventions as tech debt seems to miss the point somewhat. Conventions and protocols often exist to keep us safe.

Now, not all coders regard themselves as engineers, and in fact some code isn’t written for customers. Many of us have personal projects, and some of us might be regarded as hobbyist programmers. I have frequently sketched out a few lines of code in a new language I’m learning, knowing full well it’s an untidy mess, or just for trying things out, like rough notes. I am a beginner so haven’t discovered or understood the conventions initially. Does that count as being tech debt? When I first started learning Python, I sketched out lines of code in the repl, and became frustrated at having to type them all over again when I revisited my noodling. Frustration is like tech debt; I learnt to write my code in an actual file I could then save, keep in version control and rerun at will. Amateurs may not be professionals, but they can still cut the mustard. In fact, amateurs code for the love of it. If you code for love rather than money, write in and tell us. Try looking back over code you wrote a while ago, whether it was for work or pleasure. You will see how you have changed your style and notice better and perhaps safer ways of doing things. It’s not that you left yourself a debt that you had to pay back to someone, with interest. It’s more that you left your future self a puzzle to solve.

Barney Dellar recently blogged about Escape Rooms, [Dellar20]. A team of people pay money to be locked in a room, and by finding clues and solving puzzles might be able to find a key to get out of the room before their time is up. Barney points out “The way we solve the puzzles now has absolutely no effect on the difficulty of the next puzzles, or the puzzles that we’ll face next time we do an Escape Room.” In contrast, when we write software, we are creating potential future puzzles. “The faster we go today, the higher the difficulty level will be tomorrow. But if, instead, we go slowly and carefully today, then tomorrow’s puzzles will be easy. And easy puzzles don't take long to solve. So we will move faster.” Perhaps instead of talking about tech debt, we should talk about hard or easy puzzles. Imagine reporting at your daily stand up that you’d created a puzzling mess that no one could follow because it was quick, and it might not work. The tone is different to saying you’ve got the code into prod and raised a tech debt ticket to make it neater later.

Steve Freeman has previously used the analogy of unhedged call options to explain tech debt [Linders14]. If you don’t know about investment banking, Nat Pryce summarised this as “refactoring now is an investment for the future / a hedge against the callable option I’ve ‘sold’ by writing bad code”. This may not help, if you don’t know what a future, hedge or callable option is. The blog explains in detail, but the high level idea is you agree, for a fee, to sell someone something in the future of a fixed price. The person buying this from you might not take up this option. Neither of you know what the items will sell for at the future date, so this is a bet: will the price got up or down? Without a ‘hedge’, or some way to ensure you can get hold of the items for a known amount at the date in the future, you could end up in a load of trouble. You will, of course, have the agreed fee up front, but that may be peanuts compared to the amount you could lose. The unhedged call option analogy, regards the fee or premium as a quick win now, which is all very well if you never need to go near the code again. If you do need to go back, you’ve left an unhedged risk. The trouble with analogies is you need to know about the parallel in order to understand the point being made. A simple way to put this (sorry for that finance pun) is to talk about tech risk rather than tech debt.

Since I’ve brought economics into the equation, consider John Maynard Keynes’ idea of the ‘animal spirit’, wherein economic decision are often intuitive, emotional and irrational. Others claim the markets are ‘rational’, the economy flows, and that twisting the right knobs and dials will have a predictable outcome. Now, Keynes is saying confidence or lack of it can drive or hamper economic growth.

Even apart from the instability due to speculation, there is the instability due to the characteristic of human nature that a large proportion of our positive activities depend on spontaneous optimism rather than mathematical expectations… our decisions to do something positive, the full consequences of which will be drawn out over many days to come, can only be taken as the result of animal spirits—a spontaneous urge to action rather than inaction, and not as the outcome of a weighted average of quantitative benefits multiplied by quantitative probabilities. [Wikipedia-3]

Some take the idea further, and talk about testosterone-fuelled macho nonsense. Whether you think women can be ‘hero programmers’ or traders, jumping in thoughtlessly and causing instability, or that oestrogen stops such idiocy, unfounded optimism and instability cause trouble. Constrain your animal spirits once in a while. Where does this leave tech debt?

Debt can be paid back at some point. The word covers up for some very challenging financial situations many people find themselves in. Risk, on the other hand, sounds more, well, risky or downright dangerous. Debt has the idea of having borrowed something from someone for a bit, like an ‘I owe you’ (IOU). The word comes from debere ‘to owe’ or ‘keep something away from someone’, from de- ‘away’ (see de-) + habere ‘to have’ [Wikipedia-4]. What has been taken from whom in tech debt? Sharp tools? Easy to solve puzzles in the future? Maybe. David Graeber’s book Debt, the first 5000 years regards money as an IOU giving a way to formalize debtors and creditors, and calls into question the idea that debts have to be paid. ‘Says who?’, basically. Religious texts, well certainly the Old Testament, decries usury and also instigates a Jubilee year “a trumpet-blast of liberty” [Wikipedia-5]. Imagine a clean slate, with all your debts paid off. Michael Feathers recently shared a metaphor for tech debt as running a commercial kitchen, but only cooking, never cleaning anything. A health inspector would shut you down. Software doesn’t have health inspectors, but does still need cleaning up for (mental) health reasons. Go one, you owe it to yourself. Tidy your house, fix your wiring, clean up once in a while. Start afresh. Bring on a happy, healthy New Year!

References

[Dellar20] ‘Creating our own puzzles’, 30 October 2020: https://barneydellar.blogspot.com/2020/10/creating-our-own-puzzles.html

[Guardian] Semantic enigmas: ‘What is the origin of the phrase “doesn’t cut the mustard”?’: https://www.theguardian.com/notesandqueries/query/0,5753,-2242,00.html

[Linders14] Ben Linders (2014) ‘Is Unhedged Call Options a Better Metaphor for Bad Code?’, posted 24 December 2014 on InfoQ: https://www.infoq.com/news/2014/12/call-options-bad-code/

[Wikipedia-1] Koch snowflakes: https://en.wikipedia.org/wiki/Koch_snowflake

[Wikipedia-2] Triangle mesh: https://en.wikipedia.org/wiki/Triangle_mesh

[Wikipedia-3] Animal spirits (Keynes): https://en.wikipedia.org/wiki/Animal_spirits_(Keynes)

[Wikipedia-4] Debt: https://en.wikipedia.org/wiki/Debt

[Wikipedia-5] Jubilee (biblical): https://en.wikipedia.org/wiki/Jubilee_(biblical)

Frances Buontempo has a BA in Maths + Philosophy, an MSc in Pure Maths and a PhD technically in Chemical Engineering, but mainly programming and learning about AI and data mining. She has been a programmer since the 90s, and learnt to program by reading the manual for her Dad’s BBC model B machine.