Technical Debt Doesn’t Exist

Technical Debt Doesn’t Exist – The HFT Guy

After decades of software engineering, I came to the professional conclusion that technical debt doesn’t exist.

Oh I have seen software rewritten countless times under the pretense of technical debt, doesn’t mean there was technical debt unless “technical debt” is defined as “any existing code”.

Software is unique in the way that everything that was written will be mercilessly rewritten (#refactored) by the next person who inherits it.

It’s very visible and begins as soon as your first project, every intern and young graduate joining an existing codebase immediately feels the urge to rewrite it. It’s a rite of passage in the industry, declare that the existing is shit and the only reasonable course of action is to rewrite it! Codename “technical debt”.

This is meant literally. Reading existing code is difficult -more difficult than writing code- thus it is a genuine take from the developer that throwing everything away and starting over from scratch is “easier” than continuing on the existing. [Ergo this is flawed for non-small projects because the new development will never catch up with the existing during the tenure of the developer(s).]

A Perception Problem in the Industry

One analogy to how software is seen is a mine pit. Every line of code is digging a little deeper.

Eventually the software developer will look back at the project only to be horrified at the gigantic hole he dug [for himself].

Then he will resign to escape from this hell hole… only to start digging up a new one nearby that will become the same soon enough.

Repeat.

Bigger is Better

The process for a mine is conceptually simple:

• Mine deeper
• Reinforce foundations
• Mine deeper
• Reinforce foundations
• Mine deeper

The bigger, the better. While size is not the goal by itself, it is inseparable from the activity. You could look at it in retrospect and size up how much has been done so far.

If it were a pyramid project you certainly wouldn’t think it’s too big, only that it’s remarkable. For reference building Microsoft Windows 7 took more work than building the Great Pyramid.

Mining understands what it’s about. A good chunk of the work is rightfully to maintain the mine in operating conditions -maintain and extend the foundations-, in order to extract more minerals and extract from deeper.

Maintenance

Make yourself a favor and call that maintenance.

Software do not have a technical debt problem, software simply requires maintenance.

The world is changing fast and there can be a lot of maintenance to do. True.

Python 3 changed all the string handling, have to make adjustments. The build is too slow, should make it faster. Security vulnerability found in one library, time to update libraries. Users have moved to using phones rather than desktops, should adjust the site to make it readable. Emails sent to gmail addresses are going to spam, gotta look into that.

That’s a forever stream of maintenance, from the environment, from customers and from every component the software is built upon. There are endless adjustments to make. I’ve written before on the life cycle of software or why products are eventually shutdown.

There is no such thing as technical debt. There is work to do, that we can agree on, but it’s not debt payment.

FAQ: What If?

What if the build doesn’t work and the software is not well tested…

Well, to get the software to compile on current gcc and to add tests can be considered maintenance. It’s a very normal thing to do as far as the development cycle is concerned. Definitely not a case of technical debt.

What if there was no source code…

Indeed it can be challenging to maintain software when the source code (and everything around the project) was lost. That sounds more like it was lost or it was never done in the first place, rather than technical debt. Definitely nothing to do with debt. [Half jokingly, debt imply to be given something and have to repay it, you can hardly be in debt if you never had anything :D].

Real world corollary here. There really are projects whose source code was never stored in the first place, no documentation, no build script, nothing. The word you’re looking for is “throwaway project” because it was meant to be thrown away (very common in contracting). Just one thing, don’t point the finger at your predecessor for it, it takes all parties to tango, neither the company cared to collect any deliverable or to have source control nor the developers cared to submit any work or to setup source control.

To make another analogy, when you bring your car to the mechanic to replace breaks after 80 000 kilometers, he doesn’t proceed to warn that the previous mechanics has left debt’ed break pads all over the place and to question the person’s qualifications. It is regular maintenance really. [However if there were no breaks, the mechanic may question how come there are no breaks and hope you didn’t pay for the car in full –the car was clearly incomplete and non-functional?-, that is still maintenance regardless, gotta (re)do the breaks.]

To conclude on a final word: Maintenance.

Conclusion

All projects begin from scratch and end in maintenance.

Pun intended because maintenance never ends!