I thought I would start my FutureThought blog with a bit of reflection on the past. This is my second (or maybe third) attempt at writing the post…I’ve come to realise that the past, even my short past, has a lot to offer.

Firstly a whistle stop tour of my history…

My professional development career started in 1994 for Ferranti International PLC on a project for a nuclear power station data processing and control system written in Ada. At the time it was the first proper job I could find. Over the years I’ve realised how lucky I was. As you might expect, software quality was fundamental to the project and that has stayed with me ever since.

After Ada I switched to C (an education in the internals of memory allocation) and worked with a meta data driven system for managing engineering product data. The pitfalls of over customisation of a flexible product were fully explored on this project…

Onwards from there onto a .Net application for collating (near) realtime train information and making available on the web (http://www.nationalrail.co.uk/times_fares/ldb/). My first encounter with Agile (this was approx 2002).  By this time Ferranti had become Syseca which had become Thales.

From there I had a brief spell at EDS, back on the engineering product data management. Invaluable observation of a large conglomerate inaction.

Then I went to Moneysupermarket.com. Starting out as a technical lead responsible for www.travelsupermarket,com, on to Solution Architect and ultimately to CTA – coal face through to management.

After Moneysupermarket I setup FutureThought and here I now am…writing a blog post and back at the coal face.

I said it would be whistle stop, the point is, I’ve been around a bit and seen pretty varied environments. In my earlier career short projects were considered anything around the 18 month mark. Later in my career 18 months is considered a (very) long project.

So, lessons learned? Clearly there have been lots, some positive and some negative. I shall attempt to extract some of the more useful or amusing…

Poor future sight
As a general rule humans are pretty poor at predicting the future (try wining the lottery, its hard) but it doesn’t stop us trying. We estimate projects to the nearest day, we build features to meet future requirements, we pick new technologies based on the future. My advice, stop trying so hard. Make decisions and be prepared to fail fast.  This is easier said than done in most corporate environments as failure is not generally encouraged.

People don’t make rational decisions
We all like to think that we are entirely rational (especially us programmers) and that it is the rest of the world that isn’t but of course that is nonsense. There is oodles of research out there that tells us how un-objective we are. Anything from gut feel, desire for new technology, making a name for yourself, peer pressure, the list goes on.

So, the next time you hear about the introduction of a new product, process, etc put your sceptical hat on, is reasoning behind the decision valid? What is really going on?   If you don’t agree with the decision (from your entirely rational view point!) then understanding the real drivers is likely to help you argue against it.

The database is your performance bottle neck
Of course this isn’t strictly true.  I’m certainly not having a go at database nor all the DBAs out there. The reality is that the majority of systems have a single database at their heart. Its inevitable that at some point it will struggle and ultimately, if you’re successful (or really heavy on the DB) you will find yourself contemplating how to scale out rather than up…although we are often too eager to do so because scaling out is cooler than scaling up (see section on rational decisions).

Don’t solve tomorrow’s problem today
An extension on our poor future prediction. The chances are, tomorrow’s problem is unlikely to be what you think it is today so you will end up solving the wrong problem. However, do think about tomorrow’s problems and how you might solve them if they become today’s problems.

Measurement is important but not the end game
If you just say you want to do something (we want the system to be maintainable!) then in my experience that desire will take a back seat as deadlines approach. If you measure that something and report it as part of the success criteria of the project then you will make sure you pay attention. The flip side of this, if you measure the wrong things you will drive the wrong behaviour – witness any organisation that uses lines of code as a measure of developer productivity…yes I have seen that and no it wasn’t a good idea.

If you haven’t done it yourself then you don’t truly understand it so rely on others you trust
This is difficult. As we get more senior we have to cover more ground. There comes a point where you can’t cover the ground and you have to rely on others. As this gradually scales up you have to rely on others more and more. Often you will find that you don’t agree with decisions made by others. Don’t fool yourself that just because you are more senior that you know better. If you want to truly understand someones decision then try walking in their shoes first.

There are no silver bullets
We all know this to be true…but why do we persist in acting like there are. Whenever a new technology or process comes in we load it up with expectation and hype that it is going to solve all problems.   Lets face it, any change is likely to have both positive and negative effects. The trick is to make changes that are net positive more often than changes that are net negative.

Context changes things
How many times have we looked at a system and shook our heads. Why did they build it that way – they should have known that the DB would become a bottle neck  Of course they probably did but there were a whole raft of reasons why this did it that way that were probably right at the time and in the context. Now the context has changed, time to rework

I’m going to stop there. Not because there are no more nor because they are my top lessons, just because thats enough for now…