Don’t write software, buy it

Alastair Aitken 30 September 2013 0

Unless you’re being paid an obscene amount of money.

Unless you’re working in a start up with a unique business proposition.

Unless you’re a software house.

Do not write software.

Buy it

If your software is designed to give your organisation a competitive advantage then that might be a reason to build your own software. However, if you’re writing a variation of a blogging engine, or an accounting package, or a markup engine, forget writing it yourself and get software off-the-shelf and then adapt it for the purpose. Rely upon the Pareto principle.

Buying without money

“Buy” does not refer merely to the payment by monies, it might mean “buying into” an open source framework or library. It’s unlikely that your organisation will develop its own Javascript library for handling user interaction in a browser; you’d need to find a really good reason to use anything other than jQuery. Although there is no price to purchase jQuery, that doesn’t mean that it has no cost: you still need to either train or be trained in its use, and its use may dictate other technology choices.

Standing on the shoulders of giants

In one contract I worked, my team was tasked with replacing the website’s session manager, which was a piece of crap that had been written in-house and failed often. The initial architecture discussions centred upon using a freely available session manager that came with the middleware we were using. We thought that we would then write an adapter for the session manager, meaning that there would be no need to rewrite the existing code. All that would have been far too simple however.

Jobs for the boys

To keep everyone in work, we were instructed to instead craft our own session manager. Once we started to design this session manager, we realised that we would need a software load balancer, so we built a software load balancer. The load balancer required an algorithm for working out how to balance the load – it’s a known problem with many defined solutions – but again, we had to create our own method. And so it went on.

It took a number of months of development, testing and implementation before the new session manager was implemented. Retrospectively we really had a hard time justifying why we had crafted it ourselves. At an architecture meeting someone proffered that the advantage of the in-house session manager that we’d built was that “if a hacker got in then he’d find it difficult to understand what was going on”. “Well then he’d be in good company then”, was what I wished I’d said, but, to my regret, I didn’t.

Fail big

IT has a track record of building rather than buying. There are public projects that failed because they should have bought in software rather than attempting to build it. Most recently the BBC’s Digital Media Initiative was cancelled after spending £98.4m on a system that arguably could have been implemented using mainly off-the-shelf technology that already existed at the project’s start date.

Are you a man or a Muppet?

During the discussion about building a session manager, one colleague put it succinctly to me: “why do the work yourself? Let some other muppet do it?”

Alastair Aitken (124 Posts)

As a contract developer and manager I’ve worked in a wide range of enterprises in a variety of countries where I’ve encountered everything from great work, awful work, bizarre work, all the way down to quasi-legal work. If you think that you recognise your own organisation within my articles then you’re undoubtedly wrong, where you work isn’t that unique.

Leave A Response »