Sunday, June 18, 2006

The generation gap

My first experiences with computers didn't come in a corporate or institutional setting – they came at home playing with the (very) early personal computers my friends and I had access to.

Computers started out for me as something that is a very cool, fun way to use electronics. They didn't start out as some way to grow revenue or increase efficiency. If I wanted my computer to do anything I had to program it. If I wanted it to do something new or non-trivial I had to learn new ways, more complex, ways of instructing it. My ability to get something from the computer was intimately tied to my knowledge of what it could do and exactly how it could do it.

I'm in my mid-thirties myself, but most of the executives and managers I've worked with are 10+ years older than me. Many of today's corporate IT executives and managers are from a generation before home computers appeared, when computer technology was neither ubiquitous or affordable. They started off with the 'big iron' systems and worked their way down to PC's as PC's worked their way up the enterprise technology ladder. They had to engage teams of operators and programmers to get what they wanted from the technology – computers were in no way 'personal'.

The power of computers and networks continues to increase exponentially, thanks to Moore's law and Metcalfe's law. At the same time the ability of corporations and organizations to really take advantage of this power seems to be increasing in a linear fashion. The gap (let's call it G) between A) what it's possible to do with the technology and B) what most corporate IT is actually doing today seems to be growing. A-B=G and G is getting larger as time goes by.

Trying new things, innovating and getting 'outside the box' are associated with risk in corporate IT, and rightly so. The generation gap, however, seems to be expressed in how that risk is percieved. The 'previous gen' thinking uses a go-slow 'command and control' approach to IT, with predictable results. The 'next gen' is plugged into the technology a lot more and is constantly looking for ways to close the gap between A&B, seeing that an increasing gap is a risk unto itself. In the world we live in today corporate IT often seems to be dominated by the previous gen thinking, with next gen thinking relegated to startups and more entreprenuerial scenarios.

Is this holding us back? I can only wonder. What I do know is that the future always belongs to the next generation, and things are going to be interesting....

What do you think?

Estimate this!

Those who do not learn from history are doomed to repeat it.” - George Santayana

We often see this quote carted out when referring to some geopolitical or societal issue. Truth is, it's a great way to illustrate the problem with up-front estimating on software development projects. We've all seen it: The client wants an estimate for how long it will take to build the system. The delivery team is newly formed, with each member having various levels of experience in the technology and or the domain, or worse, there is no team yet and a smaller group (who may not even end up on the project team) has to put together the estimate.

This initial estimate will often be done bottom-up – the project will be decomposed into small units of work (e.g. features) that each get estimated separately. These small estimates are then summed up into the overall estimate. Unfortunately, these estimates are often wrong, sometimes dooming the project to a 'death march' situation.

So what have we learned about estimates?

  • Estimating learning #1: Any newly formed team is very bad at estimating at a granular level early on in a project, and pretty good at doing the same thing at the end of a project.
  • Estimating learning #2: Any estimate carries with it a set of critical assumptions that are often not communicated.
  • Estimating learning #3: Personalities play a big role in early estimates. People who are overacheivers or who are seeking approval from others tend to give very optimistic (and innaccurate early estimates. People who lack confidence, who are conservative or are risk averse tend to give very pessimistic early estimates.
  • Estimate learning #4: The past is often the best predictor of the future. If you have metrics that are applicable, then use them. For example, if you built an application of similar scope in the past, this is a good metric to use to check your estimate. Better yet, if you know the velocity of the team that will deliver the new project, you can use it to help develop your estimate.

What's the bottom line? Base your estimates on what you know (no guesses) and make all of your assumptions explicit. This means that, early on in a project, you typically have to avoid bottom-up estimates based on tasks or features, and instead derive estimates based on similar projects whose size is already measured. This initial estimate can then be refined as the project produces more data and more assumptions are validated.