|
|
Animal Farm
"We can't stop here - this is bat country" - Hunter S Thompson - RIP
|
|
|
|
|
dandy72 wrote: and if you rush the chicken to produce eggs quicker, you'll end up with a burnt out chicken before long.
And yet sales keeps telling the customers that the company has a golden goose. 
|
|
|
|
|
Marc Clifton wrote: you have to break a few eggs to get the job done
I know a fellow who uses that expression often, mostly to excuse the collateral damage caused by various upgrades. I'm glad he doesn't run an airline.
|
|
|
|
|
raddevus wrote: since this was originally written (1982 or so).
Try 1975. 
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: Try 1975.
Yeah, you are correct that the original Mythical Man Month was written in 1975 but I wasn't sure if this was part of the original or the revision (1982) so I guessed the latter so I woudln't make it sound too old.
modified 20-Aug-19 15:35pm.
|
|
|
|
|
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 
|
|
|
|
|
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
|
|
|
|
|
All of that reasoning is actually another example of how software is in the state it is in now too. 
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!!"
|
|
|
|
|
This is exactly why you were banned from Tinder.
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!
|
|
|
|
|
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
|
|
|
|
|
I keep having to tell my boss he can't schedule the release of work which isn't done yet.
|
|
|
|
|
Third choice, make a smaller omelette.
If an omelette isn't ready in thirty seconds you're doing it wrong.
|
|
|
|
|
Nice
I've often had to temporarily break a piece of software to add new features and referred to it as breaking a few eggs to make an omelette.
|
|
|
|
|
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
|
|
|
|
|
I have nothing to add, other than: this is the best thread that has ever been on CodeProject. 
|
|
|
|
|
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.
|
|
|
|
|
Slow Eddie wrote: "Oh, can you add some mushrooms?", once you already folded the omelet.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Great points.
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
