Software has a unique place in engineering in evolving significantly in design during its construction (often while people are actively using it). Its abstractness, too, makes it hard to get a real sense of what effect changes have on schedules or further work; there is nothing tangible to have our instincts work on.

The issue rears its head particularly when discussing feature plans: there are features that, throughout development, require similar amounts of work to make and some that require orders of magnitude more effort when added later versus being planned in from the start. This huge divide in cost between seemingly similar feature sizes can often challenge recipients with seemingly arbitrarily different estimates. These problems are only exacerbated before an architecture has been decided upon.

However, this difficulty isn’t only a problem – the communication loop between the product owner and the lead engineer allows the airing of ideas that the engineer alone might dismiss as being too hard to be worth it: but, by causing a second of pause, to, in a thought experiment, imagine actually designing the feature in and quite what it would involve, much more consideration is allowed.

For me, the 10 second estimation process roughly involves: while keeping in mind the pre-existing model of the system, I run through all of the parts that would need to be augmented, either categorizing them as one of “should be easy”, “it’ll take a bit of time but no surprises” and “I have no idea how that would work” or breaking down that part into smaller parts which can be categorized. These categorizations, in aggregate, produce an estimate, much like any project planning process. The specialisation is needed in both the fitting the augmentation to pre-existing systems (and therefore knowledge of that system) and in the instinctual categorization of the parts.

Crazy estimates are often a result of hitting a “no idea” categorisation, a point where intuition and experience fail and someone either needs to try it, or read up on how it has been solved in the past.

Although it’s frustrating from both sides, a clearer understanding of why this is so difficult will undoubtedly help – when the engineer understands that without the intuition, the experience, estimates are near impossible, they’ll be able to explain the difficulties certain features have. Even better, instead of rejecting features outright they might suggest another approach that would be feasible, armed with the specific issues with the feature which jumped out at them.

And on the subjects of software cost estimates, I enjoyed:

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.