Debt help sign

Technical Debt: Engineers, you are not alone

I don’t read many books about software or technology these days, I tend to read outside the domain: economics, business and management – which after all is much of what I do in the technology world these days.

Recently I’ve been reading Winning now, winning later by David Cote and find really interesting. He hardly mentions software and never mentions agile but he is giving me a new perspective on technical issues, particularly technical debt (or technical liabilities as I prefer to call them). He talks about issues which have similar characteristics to tech debt but are completely different, legal issues for example. He sees these issues as conflicts between short-term thinking and long-term thinking.

Cote’s argument is that short term actions should support, not conflict, with long term goals. I agree. It might not be easy but if actions in the hear-and-now conflict with longer term goals then the chances of reaching those goals is diminished.

Cote is writing about his time as CEO of Honeywell – a US industrial conglomerate if you don’t know. Unusually Cote is honest about many of the dirty problems the company faced when he took over – a lot of business books glossy over such problems or talk about “challenges” or “opportunities”.

For example, Cote describes how Honeywell managers were chasing numbers and targets every quarter. They had no time for long term improvements because they were so busy “making the numbers”. One of his managers cut down a forest to sell as timber in order to make the end of quarter numbers. Sales people would give products away to new customers or offer large discounts at the end of the quarter. However customers knew this would happen so delayed orders until they were sweetened.

Making the short term numbers meant the company undercut itself so lost revenue next quarter. Management time was spent finding accounting tricks to “make the numbers” rather than improving the business. And since targets ratcheted up the next quarter was more difficult and required more diversions.

Other examples included legal cases Honeywell was fighting: spending time and money on lawyers, building up bad will with customers, politicians and local people. This in turn made it more difficult to get support when the company needed it.

I read these examples, and others, and I hear an engineer saying “Technical debt.” That is exactly what it is.

A software engineer who does a dirty job on a code change because they feel under pressure stores up problems for themselves and future engineers who need to do the next change. Which is exactly the same as a factory which dumps waste into a lake as a quick fix and then needs to clean up the lake later.

Actually economists have a term for this: externalities. These are the costs which are forced onto other payer, e.g. the factory saves money on waste disposal but the local government has to pay to clean the lake. I’ve long thought a lot of “technical debt” could be considered an externality because it pushed the cost onto someone else.

Today it is probably harder than ever to escape these cost – in code, in law, in financing – because there are more and more people out there looking for these things. Environmentalists look at waste in lakes, society expects companies to pay if they pollute and courts make companies pay. Smart investors will look closely at a firms accounts and discount the firm, or short them, if they see dubious practices.

This is Cote’s argument: in the short term it might save or generate money to fight legal cases (deny deny deny), sell off forests, discount sales and such, but, in the longer term – and the longer term might just be weeks – it will costs. And when it costs it will damage growth.

Doesn’t that sound just like technical debt/liabilities?

Naturally it is hard to see a company that chases numbers, pollutes and fights all legal claims caring about the quality of code. Engineers will have a hard job fighting for technical excellence there.

Cote argues, and I agree with him, that it doesn’t have to be this way. Acting responsibly and thinking about tomorrow – whether that is pollution, sales, accounting, code quality – will make it easier to grow later. Just because it is difficult to act in a manor that meets todays needs and make the world better for tomorrow does not allow use to ignore it: all of us need to think harder and find a solution that doesn’t mortgage tomorrow.

And sometimes the right answer is to accept the slow path, take it on the chin, pay the cost you’ve been avoiding. For Cote that mean settling legal cases and accepting some costs, for software teams that means doing the refactoring, rewriting a module or just saying No to more changes.

As I’ve said before: in software the long term comes along very soon.

As as I’ve blogged before there is no such thing as quick and dirty, only dirty and slow.

We might talk about debt/liabilities but really we are talking short-term v. long-term, a pay-day loan v. investment. Engineers have an unfortunate habit of talking about technical debt as a binary good v. evil debate with no other options.

Finding these less obvious paths which satisfy the short-term and long term is hard(er) but also offers the opportunity for higher, and longer, term improvement, something which is itself a competitive advantage.


Subscribe to this blog by e-mail and download Project Myopia ebook for Free

3 thoughts on “Technical Debt: Engineers, you are not alone”

  1. You lost me at OKR because I was like “Ok, are you going to tell me what OKR means so I don’t have to open another tab? Ok-I looked it up and it sounds like hogwash. So I guess about level par with capital A Agile. Fun. Ok-NOPEx3

    1. Sorry Mike but its my turn to say “You lost me.” The post you commented on doesn’t mention OKRs, I know a lot of my others do but not that one so I’m not sure what you are commenting on.
      Maybe OKRs are hogwash, I’m happy to enage in that conversation if you say more.

      1. Ok-umm I thought you had me there. When I was reading the blog post “OKRs top-down? bottom-up? or ripples in a pond?” I jumped to the bottom of the page to comment, but wasn’t aware I was commenting on a different post. I was drawn to your site because of the “Agile is a Virus” post, because I believe the title. I should have known it was an ambush, but I let my guard down. I’ve seen what the virus does to people, and I don’t think there is any herd immunity. Some people get caught up in the process and seem to accept their fate without consciously accepting it, and others are able to see what’s happening and get the hell out of there and never look back. To some developers, Agile was its most agile when it snuck up on them. People with odd titles like product owners and scrum masters began swarming around the office demanding, in a polite way, for estimates on tasks and stories and epics. The word customer had always been synonymous with customers, but now it was a confusing set of what by all appearances were employees. Employees that needed training and guidance, but nobody was there to train them and they certainly never asked. People with hadn’t written a line of code in their lives began telling developers what their code should do and then sat silently as managers pressed every morning about deadlines during a strange ritual called stand-ups, where everyone sits in chairs.

        I hate Agile. If I knew what it was before I chose to be a software developer I never would have done it. I feel every kind of emotion a person could feel about it, mostly the sensation of an itch you can’t scratch, bugs crawling on you but there really aren’t, riding the train to work when you realize you forgot to put on deodorant, an embarrassing moment you can’t stop thinking about. OKRs remind me of similar feelings. It’s more grading developers, shaming them when things don’t go as planned, putting them on the hot seat day after day when all they want to do is sit in a dark corner of a dark room and code.

Comments are closed.