Hacker News Reader

> I am tired of the argument that we unique snowflakes amongst all professions

Aren't we, though? Zero marginal cost of production is at least very rare. It basically means that to the extent that our projects aren't novel, then we're wasting time duplicating something that ideally would have been copied from elsewhere.

And that not even getting into the very high rate of change in tools, techniques, and materials (e.g., http://www.jcmit.com/mem2013.htm), which, if not completely unique, is certainly unusually high.

> But when you see very wide ranges on an estimate, it's a signal that the problem is poorly understood.

That is occasionally a sign of idiocy. But at least on the projects I see, it's much more often a sign that it's an interesting problem. Indeed, if you're delivering software in a competitive market, it's guaranteed the problem will remain poorly understood, because your competitors will be doing their best to create changes in the landscape.

> Aren't we, though? Zero marginal cost of production is at least very rare.

Every profession can come up with a comparable point of uniqueness. Perhaps I should have said "special snowflakes" instead of "unique snowflakes".

> It basically means that to the extent that our projects aren't novel, then we're wasting time duplicating something that ideally would have been copied from elsewhere.

This is a good argument. It reminds me of DeMarco's argument that as time goes on, software engineering becomes less and less about process, because anything that is repeatable will be automated. All that's left is the hard bits that can't be automated.

There is, however, an enormous amount of duplication in our industry. And even when we are adapting an existing system, we're still only rarely performing acts of genuine novelty. Carpenters produce many items, none of them quite identical, but they aren't inventing new methods of carpentry or entirely different kinds of furniture on every job.

> But at least on the projects I see, it's much more often a sign that it's an interesting problem.

I envy you.

> Every profession can come up with a comparable point of uniqueness.

Not in ways that have such dramatic effects on predictability of costs.

> There is, however, an enormous amount of duplication in our industry.

Sure, but if we're going to put our attention somewhere, I'd rather we work on eliminating that waste, rather than standardizing the waste so that we can better estimate the cost of doing work we didn't really need to do.

Your last remark is true, but a bit falsely dichotomous. The choice isn't between perfect estimates and zero wastage. In practice all projects lie on a continuum between totally novel and pointless duplication. Within that continuum we can draft estimates of varying accuracy and I don't see a reason why we shouldn't.

The amount of time we get is fixed. Estimation is, from the Lean persepective, muda (normally translated as waste). If I can be spending that time instead on an activity that reduces the waste of duplication, I'd rather do that.

I should be clear that I'm not totally opposed to doing estimates. I've done a lot of them, I'm good at it, and there are circumstances where I would do it again. Some waste is temporarily necessary.

What I'm pushing back against here is the common assumption (which maybe you don't have) that estimates are generally a good thing to do, or, often, the only way to do things.

> If I can be spending that time instead on an activity that reduces the waste of duplication, I'd rather do that.

Estimates can prevent waste by giving us a better of idea where to redirect effort. Time is, as you say, doled out at a constant rate.

The highest ROI possible for an estimate is to prevent wasteful effort from proceeding.

Timeboxed systems still perform estimation, you just hold different variables constant. In flow-based systems you can perform estimates by taking an integral of the current output.

My point is that estimation is always present, even when we go out of our way to say that it isn't. They lie on a continuum from gut feel to supercomputers and conference papers. Estimates are always present because humans must always reason under conditions of uncertainty; the future is strictly unknowable.

Part of the confusion here is that I think there are two or three definitions of estimate in this thread. I am talking both about the universal case and the methodical estimate-with-an-E case. The universal case is that all decisions leading to action or inaction involve estimation. The methodical case is that estimation for software development is possible and tractable outside of genuine research.

I think that it is on a spectrum from sysadmin work to software development work. The closer something is to engineering doctrine, the closer it is to systems administration. If company A wants a Linux VM with Apache and some static pages, there is some per-customer work versus company B, but it is very easily estimated. All of the differentiation lies in cost or customer service at that point. And there is a lot of corporate programming that gets close to that, and is more estimatable than other stuff.

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.

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...

[2] http://www.urbandictionary.com/define.php?term=estimate

The Manhattan Project was authorised because it could be shown that an atomic weapon was possible. Nobody had any idea how to build one or how it would work -- they just knew that a calculation based on runaway radioactive breakdown implied a large release of energy.

But how often are we doing a Manhattan Project, where research is a major initial output? Not very often at all. Throwing out estimation for all projects because some of them contain genuine, irreducible novelty is an example of the Nirvana Fallacy.

> But holistically speaking, in real software-centric systems, it happens: particularly when hardware, external system integration, some form of regulation, unique knowledge individuals, or any kind of third party are involved.

These are examples of uncertainty, not novelty. They exist in real non-software-centric systems too. The way you deal with them is to widen the ranges on your early estimates and then look for ways to reduce the uncertainty.

Edit for your edits:

> In the real world, people truck on anyway with relative confidence and frequently reform an informal estimate along the way.

Nothing about having a deliberate estimations process means "we will only do it once" (I suppose that's why you said it's a waterfall thing to do). In fact you should be re-estimating as you go to narrow the cone of uncertainty. One of the nice thing about agile methods is that this tends to be built into the overall loop.

> Perhaps with the 'agile' trend we're finally shifting beyond that.

Agile estimation works by frequently re-estimating. Traditional estimation works from size and then derives other measures. Agile holds other measures constant and then takes the integral of current velocity, which is ... size!

Even the word velocity correctly points out that both of these are two sides of the same bit of conceptual calculus.

> without wasting time hiring a project manager to estimate

Where did I suggest this? In software estimating the consensus is that the developers should be the ones who create estimates. They know the most about software development in this particular environment, after all.

All fair enough.

Perhaps what we can take from this constructively is that you could consider making the USP for your estimation tool more of a focus on uncertainty/overall project risk modelling more so than straight up timeframes, which we all know are pie-in-the-sky at the best of times and not really as critical as outright SPOFs/third party deps.

I'm taking the PERT 3-point estimation technique as my starting point (decompose the project, for each component, give best/likely/worst, roll up results with a formula). It bakes uncertainty and probabilities directly into the outcomes.

I'd encourage users to look at estimating project size first and then deriving effort, schedule and cost. But I won't constrain them to it.

PERT, eh? 1950s dies hard! It's good to have a model though. I would still ramp up the big-picture risk side. One benefit of that is that you could consider tying in to an operational risk management system with onselling potential to client projects post-launch. I am looking right now but finding it hard to locate anything meaningful in this area, probably as it crosses many units of conventional businesses. Also, you may like https://github.com/mdaines/viz.js/ which I recently found generates high quality SVG vectors from graphviz input in pure JS which you can make clickable/interactive and will print at any resolution: I'm using it in a cloud infrastructure management console, myself.

> PERT, eh? 1950s dies hard!

Reading the research has been fascinating. There's a bunch of papers which show that it improves estimate accuracy; still other papers where the problems with PERT are neatly highlighted (imagine the idea of a sub-critical path and wondering how many there might be).

One of my favourite facts about the classical PERT 3-point is that nobody has a good answer for why those particular formulae were chosen. They've simply passed into the literature as-is. Probably everyone looks, recognises something that approximates the normal distribution and mutters to themselves "yes, yes, I guess that's why".

Very silly, of course. Project outcomes don't resemble the normal distribution! So there's literature where this or that alternative formula is substituted for the originals. So I've made sure that part of the design is configurable.

> I would still ramp up the big-picture risk side. One benefit of that is that you could consider tieing in to an operational risk management system with onselling potential to client projects post-launch.

I'm hoping to keep it relatively narrowly focused, because there's the real risk of bloating by trying to invade multiple neighbouring problem domains too soon. Estimates have surface features in common with work breakdown structures, with quotes, with risk management ... you can get spread too thin too soon. I'm wary of that. I'm hoping to focus on making 3rd party integration as easy as possible instead.

I have heard that it is actually just as bad on large construction projects and that the trend there is to move towards more lean approaches.

Actually, the statistics show that for very large projects, what matters is making sure to be extremely thorough in the upfront stages. See Industrial Megaprojects by Merrow for a thorough discussion, backed by data.