A Sticky Future

Thursday 2 September 2010

When I started to develop commercial software in the early eighties the general approach to writing code consisted of finding something that someone else had written that was similar to what you wanted to do, hack it around until it did what you needed to do, change the author and then show off at how fast you had been able to write the code from scratch.

This worked fine. It got me quick results and the code generally worked after a few compiles.

After a while, this approach got boring. The more experienced I got the better I thought I could do things. Why start off with someone else’s code when I could start from scratch and come up with something that from a source code perspective is more pleasing on the eye and is a little more challenging to do? It’s much more fun starting with a blank canvas…

Personal development and making your day more interesting is one thing but from a company perspective, this was probably not the best and most financially prudent way to be going about things…

As time went by I started to get into research and development which allowed me to push my knowledge further and further and experiment more and more in coming up with bigger, better and faster technologies that could be applied to build new innovative solutions and services.

I was joined by a number of like-minded people with similar backgrounds and ideas about how to code. If there is something that exists that does what you want, write your own version to show that you can do it better than the original and then do the bit you were meant to be doing later…

Now I own my own company and employ my own people I realise just how scandalous this approach was and how things appear to have changed for the better.

Why re–invent the wheel? Surely the biggest advancements that can be made are through the adoption of proven techniques and standards and then seeing how you can add value to those technologies to extend their capabilities and improve what was already there not always throwing away the blueprint and starting from scratch.

In one of my previous roles, after years of self-indulgence and profligacy, there was a big shake-up in the development team. A guy came over from the States and said how things were going to change.

“From now on we will be writing glue” he announced.

Horror above horrors! The team was in an uproar.

“We write clever code not glue” the team muttered under its breath (and in the pub afterwards).

It felt like being told; “From now on son, you’ll be on full-time support” – the ultimate nightmare for a software developer.

All of the fun of what we did had been taken away by the fact that we were now going to be sticking bits of code together with gaffer tape and glue.

How right this guy was and how wrong we had been. The software has evolved and continues to evolve rapidly. New standards in the way products interoperate coding techniques, the amazing open source fraternity. There is such a wealth of extremely clever stuff out there that you can use to create amazing and new products and solutions faster than ever before.

These are exciting times. Writing “intelligent glue” is now where it’s at.

Take our product CXAIR. We have taken some of the best in open source technologies such as Apache Tomcat, Java, Lucene, JDBC, more open standards than I care to mention etc…, etc…, and created something that is new. An amazing Business Intelligence Tool that is faster and easier to use than its competitors because it’s built on the latest and greatest proven technologies.

Our experience has allowed us to glue these components together and build intelligent layers on top.

This might make things sound really simple well I guess it is; however don’t underestimate how much glue you are going to need.