As always, Wikipedia does a pretty good job of defining well established ideas and the hypothesis of the technological singularity is no different:

http://en.wikipedia.org/wiki/Technological_singularity

While the term ‘technological singularity’ is credited to Von Neumann in 1958, my favourite definition of the singularity (for the purposes of this blog post and despite the fact he never actually used the word) was written by Isaac Asimov in a short story called The Evitable Conflict. It was first published in an issue of Astounding Science Fiction in 1950 and later that year included in Asimov’s collection I, Robot:

‘And you said, “Have your boys check them and make sure, anyway.”’

‘Susan, you read my mind. It was what I said, and he said he couldn’t.’

‘Too busy?’

‘No, he said no human could. He was frank about it. He told me, and I hope I understand him properly, that the Machines are a gigantic extrapolation. Thus- a team of mathematicians work several years calculating a positronic brain equipped to do certain similar acts of calculation. Using this brain they make further calculations to create a still more complicated brain, which they use again to make one still more complicated and so on. According to Silver, what we call the Machines are the results of ten such steps.’

‘Ye-es, that sounds familiar. Fortunately, I’m not a mathematician. –Poor Vincent. He is a young man. The Directors before him, Alfred Lanning and Peter Bogart, are dead, and they had no such problems. Nor had I. Perhaps roboticists as a whole should now die, since we can no longer understand our own creations.’

Eerily – Asimov had started writing about positronic brains and robots in 1939. Four years before Alan Turing managed to get Colossus working.

A mathematical singularity is a point beyond which you see odd or unpredictable behaviours. In computing the hypothesis goes that eventually humans will create a computer that is smarter than the human brain. At which point computers will be able to develop themselves faster than humans can keep up. We won’t be able to understand how they work anymore or predict what they will do next. Also the speed of development will continue to increase exponentially such that it will tend toward infinity – so who knows what will happen after that? It is this idea that has spawned a huge amount of academic theory as well as many Hollywood films such as Robocop and Terminator.

Just so you know Ray Kurzweil says this will happen for real in 2045. And the extract above, written by Asimov in 1950, was based in 2064… Not a bad effort.

In this blog post I’m not going to try and predict the future of computing – I’ll leave that to Kurzweil and his friends – but I’m am going to discuss how we can apply the idea of a singularity to ‘technical debt’.

When software projects get bogged down and grind to a halt…

We are often making decisions about our code that accrue ‘technical debt’. In professional software development time is money. We might choose to write a bit of hacky code now to complete some work more quickly, (imagine we are loaning ourselves time from the future), but we are likely to pay ‘interest’ on that loan in the future as we waste time maintaining our poor code.

If you are interested in reading more about technical debt, once again Wikipedia is a good starting point and this page (at the time of writing) includes some good citations by the likes of Martin Fowler and Girish Suryanarayana:

http://en.wikipedia.org/wiki/Technical_debt

So what happens if the interest we owe on our technical debt starts to exceed the number of man-hours in a working day? Well, I call that the technical debt singularity. This is the point at which software development grinds to a halt. If you spend practically all your time firefighting and you can’t release often (or ever?) with confidence, I’m afraid I’m talking about you. You’ve pretty much reached a dead-end with little hope of making significant progress. Sorry about that.

Now I‘m not saying technical debt is always a bad thing, any more than loans are always bad, but if you want to avoid reaching a technical debt singularity it is important to keep our interest payments under control by paying them down (refactoring bad code, writing automated tests, fixing poor processes etc) or by not taking out more loans than you can afford (writing too much hacky code) in the first place. This can be hard but I find it is more manageable when teams adopt any of the following strategies:

• Source Control to better manage changes. Thankfully this is pretty much a given for most people now.
• Thorough automated testing. Adopting Continuous Integration and/or Continuous Delivery.
• Better teamwork/communication across IT teams. Adopting a more DevOps approach.
• Better communication with business managers to help them understand the consequences of shipping features too fast without time to focus on quality. The business guys will want you to ship quickly now but they’ll also want you to be agile later in the year right?
• Keeping track of technical debt visually, monitoring it and paying it back (refactoring it) when possible.

Credit to @cj_smithy for this nice visualisation to help us think consciously about technical debt #redgate pic.twitter.com/iRkuOToYiu — Alex Yates (@_AlexYates_) August 19, 2014

The scary thing is how common development teams get into a position where it is just too late to avoid. They are past the singularity, the point of no-return. Sometimes they’ll struggle on in vain, introducing more bugs than features, sometimes they’ll decide that a ground-up re-write is the easiest way to fix the problem. It’s never easy. My view is that a very large portion of software teams are either already in this position or they are approaching it. When they do reach it their options are limited.

What I’m really trying to say in this post is…

Happy New Year!

If you make one professional resolution this year let it be to think more long-term. I know it seems really important to hit that deadline in the middle of January, but there will be more deadlines in February and March and July and September and in 2016. Let’s try not to hit our January deadlines at the expense of the future. And if your January deadlines are unrealistic (without accruing an unmanageable amount of technical debt) try to find a way to explain the real cost of this debt to whoever sets your workload/deadlines – in a way that they can appreciate.