“An expert is someone who has made all of the mistakes that can be made in a very narrow field” – Niels Bohr

When I got my first job in programming, I was eager to show off all the skills I’d learned over the course of my university education. Sure, I was coding in a language I’d never used before and almost everything I was doing I’d never done before, but I’d used many different languages and there were plenty of websites out there with examples of how you can do stuff. What possibly could go wrong???

When the senior developer who was mentoring me said to me “you’re the kind of developer who…who likes to write a lot of code”, I couldn’t see that as a criticism. It was a compliment wasn’t it? I mean, lots of code = lots of productivity, doesn’t it?

There was even one day I remember where I wrote 2000 lines of SQL and I thought to myself that was a pretty good days work. Nowadays I just think “WHAT?!? Two thousand lines of SQL? With how many tests???”

But I was gradually learning and improving. After I got my next job, I worked hard to deliver all of the immediate requirements that came in. At my first pay review, my manager said I was doing a good job, said he’d had some good feedback, and added

there is one thing that I want to talk to you about and that’s your visibility. Actually I’ll talk to you about it in your performance review in a couple of weeks.

Now I wondered what on earth he could be talking about. My eyesight was fine, no need for glasses at all! During the next couple of weeks, there was a departmental restructure and I got a new manager. So it took me a little while longer to understand about this thing called visibility, but I would wager that I’ve learned it better by learning it from my own experience.

In Code Complete, Steve McConnell gives a good example of a wicked problem (a problem that can only be clearly defined by solving it) which is the collapse of the original Tacoma Narrows Bridge.

This is a good example of a wicked problem because, until the bridge collapsed, its engineers didn’t know that aerodynamics needed to be considered to such as extent. Only by building the bridge (solving the problem) could they learn about the additional consideration in the problem that allowed them to build another bridge that still stands.

One of the key lessons that I really wish they’d taught me at University is users always want for today, and do not think very much about the needs of tomorrow. It is the professional software engineer’s responsibility to get the users to also think about what might go wrong and find out how much of a problem it would be if it did.

You may dispute this and say that it is the responsibility of the responsibility business analyst, or the project manager, or the senior responsible officer, or anyone by you. But is is very very important to appreciate that even with the very best IT professionals around you, much of the time, perhaps most of the time, things will get missed, not considered, or forgotten about. This is mainly because there is always a pressure in business to deliver solutions quickly, within budget, and on time.

So in the case of the original Tacoma Narrows bridge, if it were a software project run by a project manager that was delivered on time and under budget, the project manager would likely congratulate his employees on an excellent job, collect his bonus for exceeding the performance objectives, and then run for the hills after watching the whole thing fall down!

“Any fool can defend his or her mistakes – and most fools do.” – Dale Carnegie

And this is a problem that transcends project methodologies. Certainly all major Agile methodologies have little to no advice on how to foresee these problems, but more heavy process frameworks are no silver bullet either, because you just don’t know what you don’t know. It would be easy to assume that the engineers of the original bridge were bad engineers, but the truth is they were actually smart engineers who just had a lack of experience.

That is not to say that there is no way that they could have possibly known of such a danger before seeing it, but without bringing anyone more experienced, the amount of work required to identify the threat would have been considerable and require a huge amount of time consuming research into aeroelasticity in a time where this information was hard to get hold of. Really, what the engineers needed was someone on the team who had already seen a similar bridge fall down to point out the danger to them and insist on the project requirements being extended.

“If you don’t make mistakes, you’re not working on hard enough problems. And that’s a big mistake” – Frank Wilczek, Nobel Prize Winning Physicist

And so it is with software, and this is the main reason why senior developers get paid a lot better than junior developers. It’s not because senior developers write any more code than junior developers: much of the time, it is better to write less code. It’s because over the years they have seen many a metaphorical bridge collapse, and it’s a whole lot cheaper to build one bridge carefully than to build one bridge quickly followed a whole lot of embarrassment and then another bridge built extra carefully.

Some companies go so far as to only ever hire senior developers. I agree that this is better than only ever hiring junior developers but I don’t think it is usually the most cost effective way to operate.

Senior developers a lot more expensive and for many simpler tasks they are no better than graduate developers. Graduate developers are roughly as good as more experienced developers at learning new technologies and are generally enthusiastic and hard working. Also good senior developers are harder to find than less experienced developers and often are not available to start as quickly. 

Finally, you might sometimes see senior developers spending too much time discussing cleverer and cleverer frameworks with each other instead of just getting on with it! The right mix of experience and youth is a recipe for better success in your business.

“Good judgement comes from experience, and experience comes from bad judgement.” – Fred Brooks

Further Reading
Seth Godin – The Art and Science of Making Things