The Butler Did It

While reading a recent post by Jeff Attwood, entitled “Paying down your Technical Debt”, I came to the realisation that the causes of the death of Compudigm weren’t the ones I thought.

There are probably a thousand theories about what caused Compudigms eventual demise – there’s probably evidence for many of them.

But, reflecting back, I’m now convinced that technical debt was the primary cause of death – or at the very least, was the illness that sapped so much of the companies energy that other issues, ordinarily minor, became fatal.

Some examples …

… rolling a proprietary form of in-memory DataSet made a lot of sense when there was no such thing available in the runtime library – but continuing to use it after a standard emerged made it difficult to integrate with third party grids and cubes.

… using a map display system originally designed for spherical coordinates (like a globe) was a quick and pragmatic way to display maps of buildings – but introduced configuration and performance issues that affected all future projects.

… storing preconfigured object graphs in a proprietary metadata store was a stroke of genius that made the system extremely configurable and adaptable – but basing that system on Delphi’s runtime support for published properties made the system brittle and difficult to change. Worse, it placed heavy constraints on the future evolution of the system – some things couldn’t be changed because someone might be relying upon being able to configure it.

… acquiring dependencies on a wide range of third party controls and libraries made it easier to deliver early versions of new functionality, but constrained (and in some cases prevented) efforts to move forward to newer development technologies.

… a queued-job architecture, where high powered servers processed jobs at the request of low powered clients, made sense when client machines ran at 300MHz with just 64MB of memory – but when the power of client machines started to rival that of the servers themselves, the speed of job queue processing limited performance unnecessarily.

What’s the lesson to be learnt here?

Technical debt can arise from taking shortcuts, pragmatic decisions, or simply the pace of time. It’s not really important where the debt came from, but that you do more than simply service the interest payments. Failure to pay down technical debt can become crippling. Fortunately, it’s almost never to late to start payments.