5 ms·

Reasonable time cost estimation is certainly possible with software. It's not particularly easy but you certainly have a better chance if you at least expose y

by derriz 12y ago

Reasonable time cost estimation is certainly possible with software. It's not particularly easy but you certainly have a better chance if you at least expose yourself to the decades of hard research on the subject and not arrogantly imagine that everyone before you started programming of flogging your "agile approach" was an idiot and knew nothing about software development. Software estimating is not a particularly pleasant task - neither for developers (they generally have no training in the area and so don't even know how to approach the problem) nor managers (who have too little technical knowledge). And since 95% of development is writing in-house CRUD stuff or putting together lightly trafficked web-pages, it's tempting to bask in ignorance and pretend that not only is the task almost impossible anyway (and so pointless) but that in-fact it's unnecessary. And for IS department mickey-mouse projects, this is probably the case. Some of us however have had to pitch fixed price tenders for large software development projects, for example. And no, the customer isn't going to accept that it will be done when it's done and that we should just start a few sprints and see how it goes. And if you get the estimate wrong (too low), you screw yourself and lose money on the project - too high and you don't even get the contract. In this environment, you learn quickly that estimation is vital, difficult but possible with the appropriate effort. And yes I hated doing it the first time but it became almost satisfying after a few iterations having gained some confidence. This assumption that a "post-industrial", agile, folksy-anecdotal approach is appropriate for all software development really pisses me off. It breeds developer myopia, ignorance, self-importance and exceptionalism. Believe it or not, engineers have estimated, planned and executed very complex systems inside and outside of software. But it's only in software engineering do you find clowns earnestly claiming that estimating or planning developing some crappy CMS system is beyond human capabilities because software is so "different" and that estimating and planning a project like the Hoover dam was easy in comparison.

napoleond 12y ago
I agree that software estimating is absolutely possible and often necessary. However, it's important to keep in mind that software engineering has much less in common with the more traditional engineering disciplines than they have with each other. A big difference is the ability to heavily iterate on a design after it's been shipped (not in all cases, and within limits, but still generally much more than a structure or physical machine). So we often see procurement cycles which treat software development like a construction project or equipment manufacturing (because the organizations making the purchase--enterprise and government--have built their procurement processes around that sort of project) even though that cycle does not necessarily match the way software "should" be built. FWIW, that procurement inefficiency represents an opportunity for software entrepreneurs who have the patience to deal with the sub-optimal process. It also probably represents an opportunity for large firms, in terms of how to cut down on software expenses (presumably by bringing development in-house, although that obviously comes with its own overhead).
- derriz 12y ago
  I'm afraid I don't fully buy into software engineering exceptionalism; software engineering is more immature but it shares far more with traditional engineering project processes than with artistic or even craft-style work (of course "in the small", for some tasks, an individual programmer uses an art/craft approach to implementing functionality). And the majority of (non-software) engineering projects also involve iteration. The majority of software projects, I believe, can be estimated with reasonable accuracy as long as you ensure the project is a development project and not a research project. Most of the literature on this subject classify the types of software projects but nearly all recognize a category of "research project" and most agree you cannot estimate such a project. Note this finding applies to all branches of engineering. A major problem I see with software engineering is developer ego resisting accepting that most of what they do is mundane and has been done many times before. They resist this ego-deflating fact by trying to turn every project into a "research" project; thus instead of using simple boring dependable tools (let's say Apache, MariaDb or Postgres and Php) to deliver working software, many developers/geeks (and I consider myself one) will try their utmost to turn the project into a research project. So it will be proposed to use a Hadoop cluster for storage and the latest cutting edge ORM tool with load-balancing and an XML based messaging bus talking to a front end written using Nimgorust or whatever cool new programming language is out there. Of course, estimating such a project is an order of magnitude more difficult than a project involving mature well-known tools. But this difficulty is a product of technical decisions (which you can control) and not inherent in the task of delivering working software.
drewcrawford 12y ago
> And if you get the estimate wrong (too low), you screw yourself and lose money on the project - too high and you don't even get the contract. In this environment, you learn quickly that estimation is vital, In my vertical what happens is that customers field optimistic estimates from vendors much less qualified than you. But customers have no basis to know those estimates are fanciful. So they rely on a fanciful estimate from an unscrupulous vendor, and then get stuck. Estimates are not judged on being right, they're judged on being low. In that environment, the only winning move is not to play. Obviously in some verticals there could be people technically qualified to evaluate the incoming bids. I'm just reporting that it isn't the case where I work.
- dreamfactory2 12y ago
  If you can't demonstrate prior track record on a similar project and are relying on price alone to win then you should qualify out in any case.
dreamfactory2 12y ago
Building projects are a terrible example of predictability. They are ultimately highly agile due to dependencies on inherently unpredictable factors such as weather, 3rd party suppliers, industrial disputes, archeological discoveries, legal disputes and so on. The difference with software is that if you have done it before you should have automated it. The great majority of programming is therefore design work. There is an answer here which is reversing the problem and simply timeboxing based on expected ROI and there is certainly no need for task estimation as a component of fixed price bidding, particularly where that has a lousy historical track record and wastes client money. (I'm well aware that on many very large projects this is not the case and they are run like an old-fashioned production line with humans performing well-defined tasks - but this only illustrates the huge inefficiencies, lousy processes, and general ignorance of software development practises as standard in SI's.) But aside from all that, how do you account for http://en.wikipedia.org/wiki/Planning_fallacy http://en.wikipedia.org/wiki/Planning_fallacy ? I'd also be interested in how you apply cost estimation to debugging and other BAU tasks.
- derriz 12y ago
  The majority of building projects are simple and predictable - like single domestic dwellings. Building contractors have gotten pretty good at estimating the cost and time (or else they go bust quickly) to complete a family home from scratch on an already serviced plot despite all the dependencies and unpredictability you describe. Applying "agile" (i.e. not doing requirements gathering/careful estimation/detailed planning and not having a clear goal at the start) would be a recipe for going bust very quickly. And the majority of development is (despite our egos) as mundane as this really. The effort is certainly NOT spent on design work; have you ever quantified the effort that goes into various aspects of delivering working production software? Re. planning fallacy, what of it? It doesn't make estimating impossible; once you are aware of it, you account for it in your estimates. You also calibrate your estimates with independent models and with empiricism (i.e. previous experiences). But the literature is extensive on this topic - I can't give a summary here but if you are interested, there are worse places to start than with Boehm; deeply unfashionable I know but built on (shock! horror!) empiricism and not the rationalist (in a epistemological sense) sophistry which dominates the thinking of "agile visionaries". Really it's like we've regressed to a pre-scientific age in the field of software engineering processes. Most of the debate seems about as relevant as arguing about how many angels can dance on the head of a pin. It seem actually observing and measuring reality went out of fashion sometime in the 90s.

by derriz 12y ago

napoleond 12y ago

I agree that software estimating is absolutely possible and often necessary. However, it's important to keep in mind that software engineering has much less in common with the more traditional engineering disciplines than they have with each other. A big difference is the ability to heavily iterate on a design after it's been shipped (not in all cases, and within limits, but still generally much more than a structure or physical machine). So we often see procurement cycles which treat software development like a construction project or equipment manufacturing (because the organizations making the purchase--enterprise and government--have built their procurement processes around that sort of project) even though that cycle does not necessarily match the way software "should" be built. FWIW, that procurement inefficiency represents an opportunity for software entrepreneurs who have the patience to deal with the sub-optimal process. It also probably represents an opportunity for large firms, in terms of how to cut down on software expenses (presumably by bringing development in-house, although that obviously comes with its own overhead).

derriz 12y ago
I'm afraid I don't fully buy into software engineering exceptionalism; software engineering is more immature but it shares far more with traditional engineering project processes than with artistic or even craft-style work (of course "in the small", for some tasks, an individual programmer uses an art/craft approach to implementing functionality). And the majority of (non-software) engineering projects also involve iteration. The majority of software projects, I believe, can be estimated with reasonable accuracy as long as you ensure the project is a development project and not a research project. Most of the literature on this subject classify the types of software projects but nearly all recognize a category of "research project" and most agree you cannot estimate such a project. Note this finding applies to all branches of engineering. A major problem I see with software engineering is developer ego resisting accepting that most of what they do is mundane and has been done many times before. They resist this ego-deflating fact by trying to turn every project into a "research" project; thus instead of using simple boring dependable tools (let's say Apache, MariaDb or Postgres and Php) to deliver working software, many developers/geeks (and I consider myself one) will try their utmost to turn the project into a research project. So it will be proposed to use a Hadoop cluster for storage and the latest cutting edge ORM tool with load-balancing and an XML based messaging bus talking to a front end written using Nimgorust or whatever cool new programming language is out there. Of course, estimating such a project is an order of magnitude more difficult than a project involving mature well-known tools. But this difficulty is a product of technical decisions (which you can control) and not inherent in the task of delivering working software.

drewcrawford 12y ago

> And if you get the estimate wrong (too low), you screw yourself and lose money on the project - too high and you don't even get the contract. In this environment, you learn quickly that estimation is vital, In my vertical what happens is that customers field optimistic estimates from vendors much less qualified than you. But customers have no basis to know those estimates are fanciful. So they rely on a fanciful estimate from an unscrupulous vendor, and then get stuck. Estimates are not judged on being right, they're judged on being low. In that environment, the only winning move is not to play. Obviously in some verticals there could be people technically qualified to evaluate the incoming bids. I'm just reporting that it isn't the case where I work.

dreamfactory2 12y ago
If you can't demonstrate prior track record on a similar project and are relying on price alone to win then you should qualify out in any case.

dreamfactory2 12y ago

Building projects are a terrible example of predictability. They are ultimately highly agile due to dependencies on inherently unpredictable factors such as weather, 3rd party suppliers, industrial disputes, archeological discoveries, legal disputes and so on. The difference with software is that if you have done it before you should have automated it. The great majority of programming is therefore design work. There is an answer here which is reversing the problem and simply timeboxing based on expected ROI and there is certainly no need for task estimation as a component of fixed price bidding, particularly where that has a lousy historical track record and wastes client money. (I'm well aware that on many very large projects this is not the case and they are run like an old-fashioned production line with humans performing well-defined tasks - but this only illustrates the huge inefficiencies, lousy processes, and general ignorance of software development practises as standard in SI's.) But aside from all that, how do you account for http://en.wikipedia.org/wiki/Planning_fallacy http://en.wikipedia.org/wiki/Planning_fallacy ? I'd also be interested in how you apply cost estimation to debugging and other BAU tasks.

derriz 12y ago
The majority of building projects are simple and predictable - like single domestic dwellings. Building contractors have gotten pretty good at estimating the cost and time (or else they go bust quickly) to complete a family home from scratch on an already serviced plot despite all the dependencies and unpredictability you describe. Applying "agile" (i.e. not doing requirements gathering/careful estimation/detailed planning and not having a clear goal at the start) would be a recipe for going bust very quickly. And the majority of development is (despite our egos) as mundane as this really. The effort is certainly NOT spent on design work; have you ever quantified the effort that goes into various aspects of delivering working production software? Re. planning fallacy, what of it? It doesn't make estimating impossible; once you are aware of it, you account for it in your estimates. You also calibrate your estimates with independent models and with empiricism (i.e. previous experiences). But the literature is extensive on this topic - I can't give a summary here but if you are interested, there are worse places to start than with Boehm; deeply unfashionable I know but built on (shock! horror!) empiricism and not the rationalist (in a epistemological sense) sophistry which dominates the thinking of "agile visionaries". Really it's like we've regressed to a pre-scientific age in the field of software engineering processes. Most of the debate seems about as relevant as arguing about how many angels can dance on the head of a pin. It seem actually observing and measuring reality went out of fashion sometime in the 90s.