11–20 of 100 posts
One thing my Dad always told me about software estimates: "Take the estimate, double it, and increase the time unit by one. So if they tell you it's a couple of days effort, that's really four weeks..."
I think the problem is that developers(including myself) tend to make estimates assuming that they're not going to find anything that makes them say WTF! Code is never perfect and it's extremely difficult to know how much time it's going to take to dissect and restructure code to accommodate your new feature.
As usual he takes a vast body of literature and boils it down into a chatty, usable book. The tables and checklists are worth the sticker price on their own.
"...The gist of why estimates are hard: every new piece of software is a machine that has never been built before..." Yes, and that's why a lightweight, repeatable estimation process beats every other way of doing it. As you continue to estimate, you create and refine a mental model of the project's complexity. For some projects, you're able to create a mental model that has high fidelity quite easily. For others, it…
But likewise, SWAGs aren't appropriate for megaprojects. A more involved process is called for.
I am tired of the argument that we unique snowflakes amongst all professions and that consequently we deserve special treatment. We aren't. All professions deal with uncertainty and most of them deal with it deliberately[1]. Throwing your hands in the air because a perfect prediction is impossible is just silly; an estimate is by definition an uncertain statement of an unknown variable.
Estimating software can be difficult because there are many points at which complexity can be multiplied (McConnell's example of the requirement "validate phone numbers" shows a span of minutes to months)[2]. But when you see very wide ranges on an estimate, it's a signal that the problem is poorly understood.
Outside of genuinely novel research, improving estimation accuracy is possible and valuable. And how often do we invent publishable new algorithms for graph traversal?
I have skin in the estimation game, as I am currently developing a tool for performing estimates[3]. I've also been researching the topic of estimations generally.
I'm mostly amazed at how people in my profession try it once, get an inaccurate result, and then decide -- "That's it! It's impossible! I tried it one time and it didn't work!". If you go into a gymnastics club and you can't do a backflip, that doesn't mean backflips are impossible in principle. It means you can't do it. Estimation is a skill too.
[1] See Petroski's To Engineer is Human, I reviewed it here: http://chester.id.au/2013/07/07/review-to-engineer-is-human-...
[2] In Software Estimation: Demystifying the Black Art.
Mature processes for delivering construction start with a budget and something called a program - an architectural program being a design and implementation independent description of the project's components and the relationships among and between those components.
Then there is the matter of age. Architects aren't worth a shit until they hit about sixty. Those running big designs have decades of experience. In the US the median age for initial licensure is 33. It's not twenty-something's freshly out of college, or even parents with grade schoolers organizing the process.
Then, in the US, there tend to be standard contracts which describe industry standard milestones and acknowledge that nobody really knows how things will change over what is often a multi-year cycle. Buildings are delivered reasonably on time and within budget because the process of contracting for the work doesn't require reinvention - even the plumber's subcontract is a standard form and tied to CSI format specifications which are tied to industry standards and to ANSI materials standards and the building codes.
Nobody roles their own using the coolest new fad. It's Java, not Haskell. If you read Hamurabi, you'll see the source of those traditions.
Most people would agree that practice makes perfect, right? I think a big issue with software estimation is that it is hard to get practice. I'd done full project estimates for 4-6 projects in 3 years of working professionally. Compared to the amount of practice I have writing code, this is nothing. How can I ever hope to get good at something if I only do it once every 3-6 months and it might take 2 years to get fee…
For example, in the SEI's Personal Software Process you estimate very frequently. Like agile, it works by attacking big problems in lots of small pieces. So instead of just doing the 4-6 whole-of-project estimates, you can also do estimates for stories, estimates for modules and so on.
The other thing to consider is re-estimating as you go. The Cone of Uncertainty demonstrates that as a project progresses, uncertainty about the problem and solution domains diminishes and so estimates can be made with tighter ranges.
> The gist of why estimates are hard: every new piece of software is a machine that has never been built before. I am tired of the argument that we unique snowflakes amongst all professions and that consequently we deserve special treatment. We aren't. All professions deal with uncertainty and most of them deal with it deliberately[1]. Throwing your hands in the air because a perfect prediction is impossible is just…
Cute metaphor, but I'm calling bullshit. Fundamentally, if something is completely new, sometimes nobody knows if it's even possible. Granted, that's almost never the case for software algorithms. But holistically speaking, in real software-centric systems, it happens: particularly when hardware, delivery, external system integration, some form of regulation, unique knowledge individuals, utilities, or any other form of third party are involved.
In the real world, people truck on anyway with relative confidence and frequently reform an informal estimate along the way. The waterfall model sux. Estimates are perhaps for many software projects tied to waterfallesque models and the idea of that most loathed of middle-managers; the non-technical project manager[1]. Perhaps with the 'agile' trend we're finally shifting beyond that. A valuable insight from a project management perspective might be We can't realistically estimate[2] this; or even know if it's possible but a software person can do that rapidly and without wasting time hiring a project manager to estimate[2], and a backup can be prepared and/or developed in tandem.
[1] http://www.urbandictionary.com/define.php?term=project%20man...
My favourite book on software estimation is McConnell's Software Estimation: Demystifying the Black Art . As usual he takes a vast body of literature and boils it down into a chatty, usable book. The tables and checklists are worth the sticker price on their own.