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
Third choice, make a smaller omelette. If an omelette isn't ready in thirty seconds you're doing it wrong.
Wrong is evil and must be defeated. - Jeff Ello
-
That's easy. Use
gitfor source control so that nobody really understands what a 'commit' does.Software Zen:
delete this;Fucking yes. :laugh:
-
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
[COCOMO](https://en.wikipedia.org/wiki/COCOMO) (and COCOMO II) is probably the only significant work regarding software estimation either before or after Mythical Man Month. And, having used it, I'm not convinced that, because of the complexity of its model, its much better than a 'finger in the air' guess, especially for enw or novel software.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
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 -
Them's fightin' words! Put 'em up! :mad: :laugh:
Software Zen:
delete this; -
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
I am amazed no one mentioned project creep.... "Oh, can you add some mushrooms?", once you already folded the omelet.
A programmer, like a woman's work, is never done.
-
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
2 things: 1 - The more time spent getting a requirements document and initial design correct, the better the estimate. Too many weak managers (i.e. not leaders) push to get "something" instead of the right thing, and the team and customer pay for that later. 2 - If a manager cannot or will not stand up to the customer (internal or external) and push back in order to manage the software development life cycle correctly, then that person lacks the leadership, management, and sales skills necessary to do the job. An effective manager makes an understandable and convincing case for doing things the right way. In the end, customers want success, not headaches and broken promises. Managers that do their job because they read how in some book, learned in some course, or got certified in some methodology are likely to fail. All those sources of information are good, but if the manager cannot synthesize that information into their experience, insight, and intelligence to figure out how to best manage a given project, then that manager needs to step aside or be replaced.
-
I am amazed no one mentioned project creep.... "Oh, can you add some mushrooms?", once you already folded the omelet.
A programmer, like a woman's work, is never done.
-
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
Upon completing the omelette, and the patron then requests that it be 3 egg omelette and not the 2 egg that you delivered, what do you do? - Cook a 3rd egg solo and sit it next to the other omelette. - start from scratch. - Cook the 3rd egg then when nearly done add in the complete omelette hoping that it looks like it merges together.
-
2 things: 1 - The more time spent getting a requirements document and initial design correct, the better the estimate. Too many weak managers (i.e. not leaders) push to get "something" instead of the right thing, and the team and customer pay for that later. 2 - If a manager cannot or will not stand up to the customer (internal or external) and push back in order to manage the software development life cycle correctly, then that person lacks the leadership, management, and sales skills necessary to do the job. An effective manager makes an understandable and convincing case for doing things the right way. In the end, customers want success, not headaches and broken promises. Managers that do their job because they read how in some book, learned in some course, or got certified in some methodology are likely to fail. All those sources of information are good, but if the manager cannot synthesize that information into their experience, insight, and intelligence to figure out how to best manage a given project, then that manager needs to step aside or be replaced.
-
Upon completing the omelette, and the patron then requests that it be 3 egg omelette and not the 2 egg that you delivered, what do you do? - Cook a 3rd egg solo and sit it next to the other omelette. - start from scratch. - Cook the 3rd egg then when nearly done add in the complete omelette hoping that it looks like it merges together.
maze3 wrote:
Upon completing the omelette, and the patron then requests that it be 3 egg omelette and not the 2 egg that you delivered, what do you do?
- Cook a 3rd egg solo and sit it next to the other omelette.
- start from scratch.
- Cook the 3rd egg then when nearly done add in the complete omelette hoping that it looks like it merges together.
:thumbsup: You make great points about the original missing something and then what do you do. Clearly, Microservices is the answer here!!! :rolleyes: Phew...just need to mention Microservices two more times and I'll get my my buzzword quota in today. :-D
-
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
A better question is, why are estimates that try to give specific timeframes important at all? I understand giving a broad swath, so the business can decide to pursue a project or not: if the estimate is "wow, this is huge", maybe they figure it's not worth doing. It seems that we've demonstrated time and again that for any non-trivial projects, estimates of completion are not only not accurate, they're mostly wildly inaccurate. Not necessarily due to the estimated work itself, but other things get in the way like support of current systems, illness, life events, whatever. It seems to me that it's a lot smarter try to break big projects into releasable chunks, and understand your dependencies. Then you might be able to say something like, "when step 1 is done, we'll start on step 2. Step 2 should take X days/weeks/months from its start date (which may not be immediately after step 1 completion)". If you can get your steps into small enough chunks to be understandable, you'll probably have a bit more success getting close to the time. Presenting things in this way makes it more understandable for non-technical people to understand dependencies and the fact the development does not have constant speed, and that they can also see progress on the overall project as we're ticking off steps.
-
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
You cannot estimate creative work at all. We, the software engineers, only pretend it's possible to avoid the job-risking discussions with patrons. It is all just gut feeling, based on prior experience with similar tasks. The more experience the engineer has, the better the estimation will be. I think the best way would be to handle it like Scotty in Star Trek: Estimate for yourself first, tell the captain 3 times as much, make it in 2 times as much, and be admired for being the wunderkind. ;-)
-
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"
-
A better question is, why are estimates that try to give specific timeframes important at all? I understand giving a broad swath, so the business can decide to pursue a project or not: if the estimate is "wow, this is huge", maybe they figure it's not worth doing. It seems that we've demonstrated time and again that for any non-trivial projects, estimates of completion are not only not accurate, they're mostly wildly inaccurate. Not necessarily due to the estimated work itself, but other things get in the way like support of current systems, illness, life events, whatever. It seems to me that it's a lot smarter try to break big projects into releasable chunks, and understand your dependencies. Then you might be able to say something like, "when step 1 is done, we'll start on step 2. Step 2 should take X days/weeks/months from its start date (which may not be immediately after step 1 completion)". If you can get your steps into small enough chunks to be understandable, you'll probably have a bit more success getting close to the time. Presenting things in this way makes it more understandable for non-technical people to understand dependencies and the fact the development does not have constant speed, and that they can also see progress on the overall project as we're ticking off steps.
Great post and I agree.
agolddog wrote:
It seems to me that it's a lot smarter try to break big projects into releasable chunks, and understand your dependencies. Then you might be able to say something like, "when step 1 is done, we'll start on step 2
That's really the core of Agile Scrum*. * I know that this could start an entire other thread about Agile and what it is and what it is not. But what you've defined really is what the Real Agile advocates. Will the real Agile please stand up? Please stand up.
-
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
The problem was the (single) omelette. It should have been 2 eggs, bacon, toast, etc. You then get to deliver piece meal: the customer stays "hungry" (enthusiastic) because they're getting a steady stream of "ready" deliverables that can be consumes and / or assembled if so desired (egg sandwich?). Someone else may repurpose it later into an omelette. You cut back or delay certain deliverables without delaying or sacrificing the most desirable parts of the meal.
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.' ― Confucian Analects
-
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!
My running partner at work occasionally shows me SQL statements that run to hundreds of lines. X| X| X| X| X| X| X|
Software Zen:
delete this;
