Estimating software like omelettes
-
Reading thru The Mythical Man Month and there are quite a few interesting items.
The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering 2, Frederick P. Brooks Jr., eBook - Amazon.com[^]
Gutless Estimating Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices --- wait or eat it raw. Software customers have had the same choices. The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save --— burned in one part, raw in another. Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers. But false scheduling to match the patron's desired date is much more common in our discipline than elsewhere in engineering. It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers. Clearly two solutions are needed. We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on. The whole profession can only profit from sharing such data. Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.
I'm pretty sure that estimating hasn't changed at all since t
-
Reading thru The Mythical Man Month and there are quite a few interesting items.
The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering 2, Frederick P. Brooks Jr., eBook - Amazon.com[^]
Gutless Estimating Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices --- wait or eat it raw. Software customers have had the same choices. The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save --— burned in one part, raw in another. Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers. But false scheduling to match the patron's desired date is much more common in our discipline than elsewhere in engineering. It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers. Clearly two solutions are needed. We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on. The whole profession can only profit from sharing such data. Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.
I'm pretty sure that estimating hasn't changed at all since t
And like an omelette, you have to break a few eggs to get the job done. ;)
Latest Articles:
Fun Exploring Div and Table UI Layout -
And like an omelette, you have to break a few eggs to get the job done. ;)
Latest Articles:
Fun Exploring Div and Table UI LayoutMarc Clifton wrote:
And just un-like an omelette, the job is never, ever done
"Coming soon"
-
And like an omelette, you have to break a few eggs to get the job done. ;)
Latest Articles:
Fun Exploring Div and Table UI LayoutMarc Clifton wrote:
And like an omelette, you have to break a few eggs to get the job done.
And just un-like an omelette, the software job is never, ever done
"Coming soon"
-
And like an omelette, you have to break a few eggs to get the job done. ;)
Latest Articles:
Fun Exploring Div and Table UI Layout -
Marc Clifton wrote:
And like an omelette, you have to break a few eggs to get the job done.
And just un-like an omelette, the software job is never, ever done
"Coming soon"
-
...and if you rush the chicken to produce eggs quicker, you'll end up with a burnt out chicken before long. I'm sure plenty more valid analogies can be added. C'mon CP, don't let me down...
-
...and if you rush the chicken to produce eggs quicker, you'll end up with a burnt out chicken before long. I'm sure plenty more valid analogies can be added. C'mon CP, don't let me down...
A bug in the hand in worth two in the SQL.
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
Reading thru The Mythical Man Month and there are quite a few interesting items.
The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering 2, Frederick P. Brooks Jr., eBook - Amazon.com[^]
Gutless Estimating Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices --- wait or eat it raw. Software customers have had the same choices. The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save --— burned in one part, raw in another. Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers. But false scheduling to match the patron's desired date is much more common in our discipline than elsewhere in engineering. It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers. Clearly two solutions are needed. We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on. The whole profession can only profit from sharing such data. Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.
I'm pretty sure that estimating hasn't changed at all since t
raddevus wrote:
since this was originally written (1982 or so).
Try 1975. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
raddevus wrote:
since this was originally written (1982 or so).
Try 1975. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
A bug in the hand in worth two in the SQL.
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
Reading thru The Mythical Man Month and there are quite a few interesting items.
The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering 2, Frederick P. Brooks Jr., eBook - Amazon.com[^]
Gutless Estimating Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices --- wait or eat it raw. Software customers have had the same choices. The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save --— burned in one part, raw in another. Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers. But false scheduling to match the patron's desired date is much more common in our discipline than elsewhere in engineering. It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers. Clearly two solutions are needed. We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on. The whole profession can only profit from sharing such data. Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.
I'm pretty sure that estimating hasn't changed at all since t
Same people who figured they could take 9 women and have a baby in one month.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
-
Same people who figured they could take 9 women and have a baby in one month.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
If one of those women was already eight months pregnant, and those chances increase if you (randomly) take more women. Or have them steal a baby, at least one out of nine should be successful! If I wanted a baby, and I wanted it as fast as possible, I'd take as many women as I could get and not take any chances :D
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Same people who figured they could take 9 women and have a baby in one month.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
Well, you can if one of them got pregnant 8 months earlier than you gathered the 9.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
If one of those women was already eight months pregnant, and those chances increase if you (randomly) take more women. Or have them steal a baby, at least one out of nine should be successful! If I wanted a baby, and I wanted it as fast as possible, I'd take as many women as I could get and not take any chances :D
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Damn, beat me to it!
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
If one of those women was already eight months pregnant, and those chances increase if you (randomly) take more women. Or have them steal a baby, at least one out of nine should be successful! If I wanted a baby, and I wanted it as fast as possible, I'd take as many women as I could get and not take any chances :D
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
All of that reasoning is actually another example of how software is in the state it is in now too. :laugh: Lead dev explains to PHB: "No, that's not really possible to build a nuclear submarine entirely from pasta." Less-experienced Dev comes along : "Oh, I can do that in Python for sure!!" :laugh:
-
dandy72 wrote:
I'm sure plenty more valid analogies can be added. C'mon CP, don't let me down..
PHB Wisdom:
If the chicken has already crossed the road, then you no longer have to implement Agile.
raddevus wrote:
If the chicken has already crossed the road, then you no longer have to implement Agile.
No, no, no - that's not how Agile™ works. The chicken stops every six inches while it walks across the road (these are 'sprints'). It verifies with the stakeholder (aka the farmer) at each point that he's getting what he wants, i.e. the chicken across the road. The farmer can adjust the chicken's route any time he likes. Of course, none of the principals notice the traffic on the road...
Software Zen:
delete this; -
raddevus wrote:
If the chicken has already crossed the road, then you no longer have to implement Agile.
No, no, no - that's not how Agile™ works. The chicken stops every six inches while it walks across the road (these are 'sprints'). It verifies with the stakeholder (aka the farmer) at each point that he's getting what he wants, i.e. the chicken across the road. The farmer can adjust the chicken's route any time he likes. Of course, none of the principals notice the traffic on the road...
Software Zen:
delete this; -
Ok, that explains the chicken, but what about the pig? :) The Chicken and the Pig - Wikipedia[^]
That's easy. Use
gitfor source control so that nobody really understands what a 'commit' does.Software Zen:
delete this; -
That's easy. Use
gitfor source control so that nobody really understands what a 'commit' does.Software Zen:
delete this;
