I was at a friend’s wedding recently. The topic of work came up. We started talking about the difficulties of I.T.

There were a few engineers there, not of the software variety, some project managers, etc, etc. We talked about projects and estimates, and how hard it is to find project managers sometimes.

We’re all often asked to estimate how long something will take.
Who the f*** knows?

When we’re designing something new, or doing something new…well I’ve never done it before…I’ll just make up a number!

I have recently found this analogy to be effective when explaining my work to people.
 - how long does it take to write a song?
 - radio songs are about 3 minutes long? so will it take 3 minutes to write?
 - there may be many versions of the song trialled or experimented with
 - different people may write different ideas, pass them around between each other
 - different versions of the song may be trialled with different audiences or critics before production
 - even when written, it still needs:
 - rehearsal
 - production
 - performance
 - if you don’t play the song for a long time, you have to remember it
 - new people to the band to take time to get to know it, and the groups style of working together

You have to sit there and think for a long time. Just read and think a lot. It can be a lot like creative writing. 
It can be a lot like improvising music. Or improv cooking.

It can also be extremely rigorous. See NASA for examples. They have excellent processes for designing and maintaining their codebase. 
They even have a database of _every_ _error_ _ever_ in their software. Ever.

For people who work closely with hardware there can be a lot of little mathematical tricks to optimise code speed and size.
As time goes on I believe I’ve noticed a trend, particularly with web development. As jobs are repeated and code is re-used,
we tend to get better at providing an estimate. I suppose this is self-evident, and stands to reason. Of course we would get
better at estimating how long something takes when we’ve done it many times before.

The scary thing is that perhaps the reason we find estimates are hard to come up with in software is precisely because there
are many things we haven’t done before as part of a project. As a consequence, we are faced with 2 choices; make up a number or,
admit we don’t know.

The technical challenge is not scary for me, in fact it is motivating and interesting.
It’s the social challenge that gets me.

If we admit we don’t know, we then take a (perceived) hit to our (also perceived) sense of credibility. Then we have to try and 
convince our non-technical management of why our ignorance is an acceptable state of affairs. Of course, they aren’t aware of the
huge complexity of the systems we work in. They see a few buttons on screen and a pretty UI. It looks simple to them.

If only they could know the horrors of writing graphics drivers. Or the pain of losing an entire code base because the company doesn’t
use version control. Or debugging C programs on Windows (I quite like C# with Visual Studio though).

I tend to believe education solves many problems. If managers of all types understood their own I.T. systems better, their organisations would run better. And of course, they’d get better R.O.I from their I.T. wages.

If “The People In Charge^TM” knew what it’s like to produce and administrate software, they might be more willing to let engineers do their job properly rather quickly, when properly is more important than quickly.

Though sometimes doing things quickly is fun too.