in reply to OpEd: Programming is not Team Sports
The reason that we can know in advance exactly how much wire we'll need when building a house is because houses are very simple systems, and because we have literally hundreds of years of institutional experience of building things like houses.
But even then, there is waste because they never seem to order exactly the right length of wire, exactly the right number of bolts, exactly the right amount of sand and so on, so even though in theory we can know this, in practice we don't because it is cheaper to make an estimate and get the product finished quickly than to spend ages figuring it all out in advance.
My experience with "Agile Systems" has been that, for small tasks, estimates and actual delivery do tend to converge over a reasonably short period of time. For large tasks (those which get broken down into smaller tasks, and those into still smaller tasks, and so on), they tend to be accurate to within an order of magnitude - that is, you can confidently tell the customer that it'll be done in weeks, but not in months, or in months but not years. Funnily enough, that's not that far off the sort of accuracy of estimates that you see in an awful lot of large "building heavy things" engineering. It's common for big engineering projects to come in late or over budget, but not for them to be an order of magnitude late or over budget.
The real benefit of agile working practices, though, is that constant feedback, constant estimating, involvement of everyone in those, and a culture of "how do we fix this" instead of "who do we blame" lets you catch overruns early. Catch them early and you can either fix the problem and get back on track or you can "manage your customer's expectations". Customers generally don't mind things being a bit late, as long as they know in advance and so can plan for it. And even if they do mind, it's still better to tell them, because they'll respect your honesty.
|
|---|