Comment by wpietri | Hacker News Reader

Comment by wpietri | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com