On Time and Lightning Fast

I think we should be able to estimate how long it will take us to build something and to build it quickly. Patrick Collison has a list of examples showing what people can do. Of course there must be cases where our estimates are bad and projects overrun, yet it seems strange that we expect not only slow projects, but slow projects that also overrun the estimation.

My wealth of experience is small, but I haven’t actually heard anyone talk about how to make better estimates for software projects. I only looked into the topic after arguing against the statement that “all software projects will always overrun no matter how long is assigned to them”.

Intuitively that seemed very unambitious. But I realised I didn’t have much material to argue against it. Through work experience I’ve learnt a process of breaking a project into smaller chunks of work (though not tiny chunks); assigning each a day estimate; and summing them. We generally finished projects, but I can’t say they finished how we planned. Clearly I need to improve my ability to estimate.

I’ve read Superforecasting and am convinced by Tetlock’s evidence that we can assign probabilities to hard to predict events, which in the long run will reflect the distribution of outcomes. If that works for geopolitical events, software and engineering projects can’t be more difficult. Can they?

I bundle software and real world engineering projects together here as I think modern engineering projects have to be both combined. It seems a flaw to keep them siloed.

That isn’t to say the nature of the two is the same. Jeff Atwood argues that they aren’t and Terence Parr has said the same. I don’t disagree with that. They know more than me there, but I find it interesting that neither claim software can’t be predicted or built well and quickly.

If we are to develop technology for the modern world we will have to be able to estimate software engineering projects and to assimilate them into physical engineering. (We’ll have to rediscover our past skill in infrastructure projects too…).

Frederick Brooks and Steve McConnell have advice that I will be testing out. I would be surprised if I don’t see some improvement in my estimates.

How to get to the next level and onto Patrick Collison’s fast list is another question for another day… Teaser - I doubt its scrum, agile, SAFe, story points, or following Atlassian’s advice and syncing slack with Confluence “to experience true productivity”.