Slashdot Mirror
The Mythical Man-Month Revisited
jpkunst writes "Ed Willis, over at O'Reilly's ONLamp.com, gives his varied reactions to Fred Brooks' classic The Mythical Man-Month, after 'having finally read it in its entirety'. '[...] simultaneously you can see just how much the field has changed since the original writing and just how much has stayed stubbornly the same.'"
What, like a manstrual cycle?
Fred's account of the 360 project still has lessons to teach, despite the intervening years. If you haven't read it, go read it.
...who'd never heard of this book?
Maybe I'm just uneducated, or maybe it's an American thing... here in England, we probably have dozens of books that are unknown anywhere else.
Join the Free Software Foundation
Since all the blather about "internet time" in the intervening years, I'm surprised they didn't re-release it under a new title:
The Mythical Man-Week.
Have you read my blog lately?
My company used to have a lot of problems with the mythical man month... that is until we switched to metric month.
We've found that we get a lot more accomplished by switching to the 10 day work week and 10 hour work days.
Now, if only Swatch would come out with a metric time piece.
If I seem short sighted, it is because I stand on the shoulders of midgets
of the more familiar, watered down version, Mmmm...Ohhhhh..., one of the favorite abbreviations of the "nucular" club.
he should have revised the title to something a little less gender biased. This is 2004 after all.
next on slashdot, O'Reilley makes fun of Henry Ford for not using computer controlled robots on the assembly line.
Brooks put forth a lot of good ideas, some of which morphed and/or were independently discovered and some that were true then as they are today. For example, he says, "Build one to throw away." Amen to that.
Another concept he brought to light was originally Harlan Mills's, that of making the programming team like a surgical team. A surgeon, or chief programmer, has primary architectural, design, and implementation responsibility, but is assisted by a copilot, administrator, editor, two secretaries, and a program clerk.
While I've never seen such a team, I have witnessed pair programming that the XP (not Windows, eXtreme Programming) folks praise, and it works quite well. It may not be a full-fledged surgical team as Brooks would've liked, but the productivity of a pilot on the keyboard and a copilot following after every little mistake certainly improves productivity.
If I've learned one thing it's that in IS/IT/CS you either adapt and move on or you end up doing tech support on the midnight shift. Plain and simple. I think Fred Brooks touched on it in "The Mythical Man Month" when he said that computer programming will never be a mature field because to excel in it you must always be changing your language focus. Lets face it, all one has to do is take a quick look at the demand for certain skill sets on the net to get a pretty good feel for what's relevant today and I'm not sure c++ is anywhere on that radar screen. Most of my work as of late has been all Java and c#, with some legacy C programming done (on low level systems only of course, nobody would pay someone by the hour to have app level work done in C these days) Sometimes I wonder when I hear people complain about how the CS industry tends to shun the old timers when the truth is that a lot of these old timers are trying to hang on to legacy technology like C++ or perl when the industry has moved onto bigger and better things.
Slashdot Moderation: From positive to terrible in 2 "insightful" posts.
The Mythical Man Month is the canonical text for managing software projects. I told my non-techie boss to read it before asking me to do stuff, so what he has an idea of what is reasonable, what is not, and what kind of hurdles we might encounter.
The perfect sig is a lot like silence, only louder
Well done indeed:
================
Regarding source code documentation:
"The most serious objection is the increase in the size of the source code that must be stored. As the discipline moves more and more toward on-line storage of source code, this has become a growing consideration. I find myself being briefer in comments to an APL program, which will live on disk, then on a PL/I one that I will store as cards."
For who among us is this not true? Honestly, you just can't shut me up on cards.
================
Definitely worth a read. To coin a phrase: LOL.
The Army reading list
Moores law predicts an increase of a thousand every 15 years. We are now in gigas, transitting into teras 40 years later.
A lot of basic technology in compilers, OSes, user interfaces, and artificial intelligence was invented under those terrible constraints.
A year ago, I was in a software engineering class where the professor made us read this book.
The only thing about this experience that sticks out in my mind is that the professor always referred to the book at the "Man Mythical Month". It was kind of hard to take any of the in-class discussions seriously with this going on. He knew his stuff, too; he clearly understood the concept of the "man month" and the mysticism surrounding it, yet he continued to hilariously butcher the title day in and day out.
The book itself was halfway interesting, but it didn't say anything that anybody with a couple years of software engineering experience didn't already know.
the surgeon team, advice that more people does not necessarily make the project get done faster, no silver bullet, and on and on. Great information and even dated stories on things like the conversion of paper to microfiche is entertaining as well...
Man months will always be mythical. Unfortunately, it's frequently in the interest of technical workers to provide their clients (internal or external) overly optimistic assessments of project feasibility. That's apart from the naturally rosy estimates of one's one programming/system admin abilities, versus a sober understanding of the full complexity of a project.
It's also hard convincing "novice" customers that will buy into the experience-proven truth that small feasibility projects make the bigger projects cheaper, more productive and more deadline-friendly. The instant gratification complex of customers is at much at fault as the hunger to get and keep jobs among the IT workers.
Also, programmers usually get into programming through hacking, pleasure programming, or other forms of "undisciplined" programming. Often, the impulsive "go at it" style is the only one they know and enjoy. That causes problems too. As anyone who has ever tried project-managing programmers tends to find out, managing programmers (especially newer ones) is a bit like herding cats.
The one ugly truth nobody likes to talk about is that buggy/complicated systems help ensure jobs. Let's face it... the fact that Microsoft software crashes a lot creates good opportunities for consultants and IT staffs to justify their jobs. And does anyone think that Oracle would have grown into a multi-billion company if there weren't so many highly trained DBAs/High Priests running around promoting its mysterious wonders? Who knows how quickly this foul fruit will sour when all of this rot is billed by the hour?
You put "bigger and better things", that should read "bigger and slower things".
There is a certain smugness at work in the idea that the architect will make better decisions here than the user will. Certainly this view is out of favor now. We normally try to find out what the user wants (somehow) and then find a way to design our software to provide this to them in the most sensible manner we can envision. I can't imagine saying "no" to the user regarding a feature...
It seems that a lot of open source development actually adheres to the original architect premise here. In this case, the developer is the user and therefore knows best, at least for himself. I always find gathering requirements to be frustrating, and it never feels like a completed task. Especially when the developer is green in whatever industry they're developing to, the users can kill the usability of an app by nitpicking it to death--there is no real overall vision.
It's a shame, IMO...
takes TMMM as an endorsement of everything XP. That's not what I took home from it...
:)
I guess eye of the beholder and all that.
I believe it was Mark Twain that said "History doesn't repeat itself, but it rhymes."
Picking on Fred Brooks' TMMM by noting it's anacrhonisms is about the most juvenile thing I can imagine. I can only surmise that the alleged reviewer was forced to read the book by somebody he did not like, and while he read the words he certainly didn't extrapolate the lessons to his present day situations.
When I re-read The Mythical Man Month I can see, in every paragraph, perfect analogies to my work today, and the work I see of other people in other fields. I can't wait to have the reviewer look at The Soul of the New Machine and laugh about how people used to build CPUs out of discrete parts, and how therefore none of the lessons of that book have any applicability today.
Who hasn't seen -- or lived -- an example of Brooks's "The Second System Effect?" The movie that I just finished working on, The Chronicles of Riddick was precisely an example of that paradigm with respect to Pitch Black. Every page of the chapter on The Second System Effect has one-to-one correspondences to the work on this movie.
There are few things that I'm dogmatic about -- but Everybody needs to read this book!
Thad Beier
I love Mondays. On a Monday, anything is possible.
[in response to a passage about developers needing their own machine (singular), and that it is supported]
Ed is missing the point here. I think that such a comment by the original author was based on the time-share days, not the more modern workstation days. "Back then", you all worked on terminals and did batch work on a central frame. Nowadays, the central server is good for no more than saving your Pr0n
If one were to generalize, I think that it would be better to say that "Teams building core applications need a dedicated developent environment in which to work; a system that is up to the task, properly isolated, and properly supported"
Part of the reason for a mythical man month in my opinion is zeno's paradox. Lead Developers create massive amounts of code and then expect the hired help to come along and understand all of their code and as well produce work of their own. Just as the hired help catchs up in understanding the Lead Developer has already replaced or added more code. It is the responsibility of the Lead Developer to create and section off as much of their's and others code as possible through API's libs, jars... Create as many Black boxes's as possible. Take responsibility for your own black box. Of course this is going to break down quickly when someone starts writing broken black boxs. Then you end up playing the blame game.
I worked for a guy who wasn't very technical. He was old school Navy, but he knew all the contacts in the government so he could keep them at bay while we were trying to write software. He used to say ...
Three men and a woman can't make a baby in 3 months.
Hey, Boss, we're going to do all the development work needed to create the product, then we're going to pitch it, take what we've learned and start over.
Donald: You're fired!
You can't get a baby in one month by making nine women pregnant.
I think Ed Willis missed one major point of Fred Brook's writing, and that is that when he was the manager of the OS/360 team, programming was focused on large system development. "Computers" weren't cheap microcomputers you store under the desk, but very expensive systems where priests (operators) in white robes (lab coats) keep it going, and commercial users were billed in dollars per seconds of computer time.
Brook's writing is focused on programming large systems like operating systems, or major Information Systems (IS) like bank's accounting, or a Wall-Mart's inventory system. These are still large complex tasks, which isn't done using a couple of programmers sitting side-by-side writing a bunch of code on a couple of PCs.
Willis' comparison to a classic book to modern programming method is laughable, because all those said modern methods (XP, Agile, iterative development, refactoring) were influenced by Brook's writings.
IMHO Willis' piece at ONLamp wasn't very insightful and didn't do much for me. I would recommend to any new or young programmer to read The Mythical Man-Month, it's consider a classic for a reason and don't get bogged down with the historic context in which it was written or trying to poorly graft modern programming paradigms onto MMM.
When I began my most recent job as a Unix Sys Admin, I made a point of buying a copy the this book and giving it to the project manager. I think it's still gathering dust on a cube-shelf somewhere.
When I think of the problems we've encountered in the intervening years and how much time, energy, money and emotional stress would have been alleviated by simply understanding half of what Brooks covers in his book, I want to cry; okay, sometimes I want to just laugh maniacally . . .
He admits freely the possibility that combinations of improvements may yield this order-of-magnitude improvement -- he draws the line at single factors. So there is no one, single silver bullet.
There is no such thing as multiple silver bullets. "silver bullet" is a term derived from killing werewolves, where it takes a single silver bullet to kill the beast. not 2, not 3, but one. One thing and it's done.
The author of the article implies that there may be several silver bullets. that's how i read this section. saying "so there is no one, single silver bullet" is redundant and alludes to the fact that there is a concept of multiple silver bullets. that's wrong.
there is no silver bullet. just leave well enough alone.
In his commentary on Brooks' work. There are a number of issues Willis comments about, including a 'sneer' at the software rent and memory rent. And other comments on the expensive costs of computers at that time. Realize Brooks' is talking about programming on mainframes, machines where you mostly did batch processing and served hundreds or thousands of users.
It wasn't all that long ago when parts for micro computers were expensive, very expensive. I remember when 16 megabytes of memory - and a lot slower than what is available now - cost US$400. I remember when an 80 megabyte hard drive cost US$420.00. I remember these prices because that's what I paid. This is less than 15 years ago. The availablility of really powerful computers for individuals at astonishingly low prices is an extremely recent development.
The lowering of prices (and the resultant raising of the standard of living for those who buy those things) has been going on for thousands of years, as long as we've had free markets to allow this to happen. But initially (or as long as someone has had monopoly control over supply) prices were high and often the items were difficult to obtain. As products become commodities, prices drop. This is why 640 MB CDs (commodity) are now as low as 16c each (qty. 100), 50c each qty. 1. 4,200 MB DVD-Rs are $1 each (qty 4), while 100MB zip disks (proprietary) are still about $8 each (almost no discount in quantity).
Willis is comparing terms and conditions now with the situation of (much worse scarcity) of 30-35 years ago, then cracks up in laughter at his own ignorance of the past.
Paul Robinson <Postmaster@paul.washington.dc.us>The lessons of history teach us - if they teach us anything - that nobody learns the lessons that history teaches us.
hang on to legacy technology like C++ or perl when the industry has moved onto bigger and better things.
C is the lingua franca of computers. Know it, and you can talk to any computer. Your word processer is written in it. Your browser is written in it. Your operating system is written in it. Your drivers are written in it. You spreadsheet is written in it. Your media player is written in it. Your shell is written it. Your scripting language is written in it.
Legacy?
> Moores law predicts an increase of a thousand every 15 years. We are now in gigas, transitting into teras 40 years later.
Yes and in 40-odd more years, faster than planck time. Moore's "law" does have a theoretical limit. Besides, he only talked about the number of transistors doubling, nothing at all about speed.
So he caught a few contemporary references in a book written over 30 years ago and that makes MMM irrelevant? If that's all you got from this book, the paper was wasted on you, because the book describes fundamental principles of software development that are as valid today as they were 30 years ago.
I first read this as "Mythical Man Moth"
So I was thinking Arthur from "The Tick" was coming back.
Imagine my dissappointment...
It's somewhat amusing that, even with the reviewer's nod to the primitive level of hardware in the 1960s when the book was first written, he still doesn't quite get the implications.
For example, where he says about programming teams: Even with the provisos listed in the book (one Language Lawyer can support two or three Surgeons, the Administrator may be able to look after two teams) this all seems excessive. I'm not clear at all on what the Programming Clerk does even after reading through the description a couple of times. I doubt the two Secretaries are truly necessary.
First, it was "Program Clerk", not "Programming Clerk" -- much of the work that person would do would be handled automatically these days by version control systems, email archives, and so forth. Which reflects on "I doubt the two Secretaries are truly necessary". Today, no. Then, yes. Remember, there were no PCs then. This goes beyond just the requirements for a mainframe support staff to keep the developers' test machine humming. This also meant no voicemail, no email, no wordprocessors (remember typewriters?), no PDAs, no shared calendar systems, no spreadsheets, no instant messaging, no project management software, paper files instead of disk files, etc, etc. Of course two secretaries were necessary, or the project leads would never get any other work done. Today, though, one part-time secretary for the team would probably be sufficient.
At least Brooks didn't include a keypunch operator to create the card decks from the programmers' coding sheets.
(And actually some of the really big projects -- like OS/360 -- did have access to some of the above technologies -- eg for document editing -- but they were mainframe based.)
-- Alastair
We were supposed to convert a large number of documents from one format to another by a certain deadline. The management had overestimated the per-person productivity, and as a result, we started falling behind. The owner of the business mistakenly believed that if he tripled the number of people, he'd get triple the output (we had 3 8-hour shifts running at one point). He found out how wrong he was, but couldn't bring himself to understand why. Eventually we got through it, but there were a lot of bumps and bruises along the way.
The insight contained in this (very old) book is still 100% applicable today. I've worked in software for 6 years now, and re-reading the book from time to time I get more and more help from it.
I wish my management read it, too. They seem to think they're gods and they can solve everything by hiring more contractors (as opposed to managing existing programmers/testers better).
Amdahl's Law just says there is a part of the work that can't be parallelized; in a system that follows Amdahl's Law, adding more resources always makes things slightly faster, though there are diminishing returns.
Brooks' Law says that you can actually make the project later by adding more people. That's because the new people have to be brought up to speed, all the team members have to communicate, so you can lose more time than you gain.
Users now typically buy enough real memory to hold all the code of major applications
Is the author saying that most people have more gigs of RAM than an install of MS Office takes on disk? I doubt any real major app fully fits into physical memory.
I think he's saying you will invariably throw away the whole implementation either all in one go or a little bit at a time, so it's wise to "plan to throw one away."... This is probably not acceptable now -- certainly I'd be embarrassed to have to do this.
I guess that's why we are exposed to so many programs that should have been thrown away. Airplane designers build and discard many mockup models to discover problems that are not apparent beforehand. In programming, you just need to build one airplane and you are free to reuse any well-working pieces from the discarded model, so what's the big deal?
"The fundamental problem with software maintenance is that fixing a defect has a substantial (20-50 percent) chance of introducing another." I do not believe the risks to be this high now in any reasonably well-run organization.
Didn't we see a study recently that Microsoft is more likely than not to introduce another vunerability with a security update? Definitely simple software maintanance should be supplemented by periodic major cleanups and even discarding/rewritting problem pieces.
"A discipline that will open an architect's eyes is to assign each little function a value: capability x is worth not more than m bytes of memory and n microseconds per invocation. These values will guide initial decisions and serve during implementation as a guide and warning to all." Even in embedded development where I make my living, I rarely see anything like this level of budgeting detail.
So assign values at granularity applicable to your field "capability x is worth not more than 100K and 0.1 second per invocation".
I think the author of the review is still in denial, despite his efforts to keep open mind. "Mythical man-month" was written at the time of small, efficient programs running on limited hardware. Now we have propotionally (and sometimes unproportionally) more complicated and inefficient programs running on more powerful hardware. This just makes software development more perilous, although the end result is undeniably more valuable to users.
Sure some problems shifted from lower-level ("this function is 600 bytes. I ought to cut it down to 200 or less") to high-level ("our app takes up 512MB when running. We need to make each feature loadable on demand to keep average user's memory footprint reasonable"). And if nothing else helps, god bless you, maybe you really have to go through each function in 512MB and shrink it from 600 bytes to 200. But overall, few things really went away. You just need to look for them in another place/design phase.
The problem is many things sometimes scale.
CPU time is one.
Make it faster, it scales well.
Add another processor(2,4,8 way), it scales okay.
Turn it into a distributed computer. Maybe it scaled, maybe it didn't.
In some cases like rendering a movie it scales very well. In other cases it won't scale as well.
Many systems (social or technical) have corresponding constraints and issues. A bit of wisdom can make it all a bit more clear.
To those who would bash the specifics of the situation decades ago, don't you think in a few decades they'll be laughing at your typing code and being all excited about extreme programming and crap?
It will be the same problems in a different frame, but by then you'll be wise enough to realize it.
If it succeeds --
Boss: And it was all my idea!
If it fails --
Boss: You're Fired!
Mod Karma -1: I sed bad wurds. If I cep my mouf shut, I wud be at riyses.
And I know I'm not the only one to think so. Some years back when I was working with McGraw-Hill (on deploying BIX for Byte Magazine), I noticed a (partially emptied) case of the books in the IT manager's office. (He promptly offered me one when I remarked on it, but I'd had a copy for a couple of years at that point. He'd already passed them out to everyone on his team.)
What I found significant about that is that The Mythical Man-Month is published by Addison-Wesley, a McGraw-Hill competitor.
-- Alastair
IF you double the number the transistors, then the transistors are also half size, which means that the electrons have half the distance to cover, so the speed can double as well. For graphics cards, performance is doubling every 12 months. For CPU chips, performance is doubling every 18 months.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
That is a damn good statement. I just got back from a 2 day CMM (Capability Maturity Model) class, and luckily my boss came too, as did his boss. They got to hear first hand from a very good instructor with years of real-world development and management experience what the CMM *IS* and what it *ISN'T*. Too many people think that the CMM has nothing to do with producing good software - and they are 100% right. The Software CMM has to do with getting a handle on how you MANAGE SOFTWARE PROJECTS. One of the benefits is to be able to more accurately hit your schedules. To the parent poster's point, sometimes you can only do things so fast. One of the great charts for project management is this:
Optimize....Constrain....Accept
COST
SCHEDULE
QUALITY
You can Optimize one, Constrain one, and Accept the other two. (sorry for the format, F'n Slashdot filters) Imagine it is a grid, and you have to put a check in the columns
Data suggests that customer satisfaction goes DOWN when you go from L1 to L2. This is because you are figuring out how to get control of your projects. After that, customer sat goes UP. This is because while your estimates and schedules may not seem that great, you are more likely to hit them. Once your customers get it, they are happy. What is better, saying you can deliver it in 6 months then actually delivering in 12, or saying you can deliver in 6 and doing so in 7?
And the CMM is no guarantee of anything, it is simply a demonstration of your maturity in being able to manage your projects. Of coures, that is if the CMM is done CORRECTLY.
My beliefs do not require that you agree with them.
This is analogus to the concept of parallel processing. Just like u cannot achieve a double speedup by turning a single processor machine to double processor the same applies to the concept of the mythical man month.
Over the years processors have become cheap and even if adding more processors doesnt make it more efficient there is (evene if only slight) difference. so we dont mind paying just about the same amount to throw more processors into the machine to achieve ecen a 20% speedup.
The whole point behind this example is that when u take the problem to say India where u get 3 people to work for the same amount of money u will not mind throwing them at the problem even if u can save just a couple of days. Because in the end the bottom line is still benifiting.
No offence to Indians( I am one) but thats just economics.
To illustrate where I think the author has gone wrong here, and I realize this is a subjective point, one should look at Mac OS X, Windows XP, and Linux Desktop GUIs. Apple tries to only incorporate in the GUI what they feel does not conflict with the overall look and feel. They don't even like to give their users control over themes. And Steve Jobs says ``no'' all the time, even though it offends everyone at some point. Microsoft tries harder to give people what they want. And the Linux Desktop designers fall all over themselves trying to be the most popular kid on the block. I'm sorry, but I find the Mac OS X interface to be the easiest to use and the Linux Desktops to be the hardest to use, and I don't think I'm alone. This guy is just plain old fashioned wrong, wrong, wrong.
If it takes 7 programmers 7 months to finish 7 projects, how long does it take 8 programmers to finish 8 projects?
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Mythical Man-Month A Myth. Nine women bear a child in one month through genetic engineering. When asked, the lead researcher shrugged and replied, "We just wanted to piss Fred Brooks off."
IANAL, but I've seen actors play them on TV
I got the same impression from the review.
For instance, Brooks talks about the importance of having a dedicated system administrator. The reviewer makes fun of this, pointing out that he has his own dedicated computer, and he doesn't need any administration.
Sure, fine, the desktop computer doesn't need someone to mount tapes on it. But someone's still gotta take care of the spam filter, the firewall, the on-site backups, the off-site backups. There's still plenty of admin work to do.
Similarly for dedicated systems. "Ha, ha! The sort team gets a dedicated 4-to-6-hour slot! How quaint!" Well, the scarce resource is no longer a machine with a compiler/linker/debugger. But how about the embedded target machines? Does every developer have one, or are there two of them in the lab, and one of them is broken, and the other effectively belongs to the alpha geek who's camping it?
Brook's comments about adding developers and increased communication costs also foresages something that happens on many open source projects: random patches arrive faster than anyone can deal with them, leading to huge backlogs for patch review.
I could go on. But enough from me; go read your Brooks again!
I don't understand. The one time I programmed on punched cards, I used comments.
/, a lot of asterisks and end with a /.
It was in FORTRAN.
The command cards in the deck would 1) cards for the source file, 2) cards with commands to compile and link the program, 3) a card with the command to print out the list file, 4) cards for input data, 5) the command to run the program, 6) a card with the command to print the output.
If you had a logic error, you had to figure it out by going through the printed list file and keeping track of what was in each variable at a given point
to see where it went wrong.
The comments in the printed list helped you keep your bearings.
There was a function on the keypunch machine that you could use to copy the card for a banner comment line to another card.
I have to describe the banner comments because of the lameness filter.
So a FORTRAN banner comment would start with a C and have a lot of asterisks on it.
Now that we are so advanced, we use a
I guess in summary, making comments on cards was easier than trying to execute in your head a printout of uncommented code to explain the output you got.
Since I made a lot of typos, I had to buy an extra box of blank cards for the course.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
The "chief programmer team" concept has fallen out of favor, with one notable exception - game development. Game projects have team members with well-defined roles, because they must integrate many elements that aren't just code. Games have artwork, music, motion capture data, maps, textures, character models, and props. Game teams look more like film production crews, with individuals responsible for specific areas. "Librarian" and "toolsmith" jobs are very real in game development. There's usually a lead "director", who is expected to know all the technologies involved.
warning: incorrect assumptions, leading to spurious logic.
IF you double the number the transistors, then the transistors are also half size,
What if they are 1/4 size? or 3/4 size but the new base is bigger? what if they are on a slot processor instead of a socket one? What if they're exactly the same size, there's just twice as many of them?
which means that the electrons have half the distance to cover, so the speed can double as well.
ehehehehe. you're funny.
http://xkcd.com/386/
When you go into, say, a Kinko's, odds are every single machine in that store, right down to the 11-inch laminator in the customer area, is leased, with a maintenance contract (if it's not leased, then it probably was leased for so long that it went off-lease and became owned by the store.) Look on the side or top of the stuff in there and you'll see a label with the lessor info: who to call, what the number is, the equipment serial number, etc.
When equipment breaks a lease saves simple hassle in the business too -- instead of having to trust some employee to monkey around in there (which you may or may not be able to spare man-hours for), you just take it out of service, have another store produce orders if need be, and call the lease company. And trust me, when you're talking about a half-million-dollar copier, you do not want to have to eat major repair costs because your screwdriver slipped and you skewered the main vacuum tube or dented the motherboard on the controller.
-- Old Man Kensey
If you'd need an infinite number of monkeys for Shakespeare, I'm thinking you're gonna need the same order of magnitude of dogs to accomplish anything.
YOu gotta remember, the monkeys might bash on the keyboard, but the dogs will just sniff each others butts.
Lost at C:>. Found at C.
Optimize....Constrain....Accept
S COPE
COST
SCHEDULE
QUALITY
I knew a guy when I was contracting to the Air Force that used to put it like this:
Cheap, Fast, Good - pick 2.
I find this to be applicable almost anywhere.
http://xkcd.com/386/
Cheap, Fast, Good - pick 2.
Except "good" can be interpreted in different ways. That is why it's more clear if you split it out into scope and quality. Scope refers to what you say you will produce, quality refers to how well you produce it.
My beliefs do not require that you agree with them.
Umm, ever heard of an IT department? Granted they rarely actually program anymore, but they're still configuring and maintaining your system for you*.
*Except of course in my job, where the great & powerful IT department is afraid to even touch a Linux machine (like the ones we use for actual development!)
"You can demonstrate a program for a corporate executive, but can't make him computer literate."
If you haven't already read the book, go ahead and pick it up. Even if you don't agree w/ what he writes, forcing you to think about this shit will make you a better programmer.
What he writes at the very end is the absolute clincher, makes going through the book quite rewarding.
[o]_O
The Bill Gates money quote is that it was Visual Basic -- the C/C++ version may run faster, but the VB one gets developed real quick.
I find that the books have the most value because they not only describe WHAT the mistakes were, but WHY people who knew better made those mistakes.
People keep making the same mistakes, for the same reasons. Even when they know better.
The trick is to identify the conditions that exist PRIOR to making the mistake and focus on changing those conditions (example: management does NOT know what they want, just that they want something and it has to be next month).
Managing the conditions is very tricky.
Not too long ago I wrote an article about software development methods which heavily focused on Brooks as a precurser of Agile methods. Those who are interested can read it here.
Of course I totally agree the book is a classic, but some major portions of MMM, to my knowledge, have never gained favor, such as the surgical team analogy to working on code, where there would be like six people involved on any major code change. Certainly the man month is mythical, but IIRC that is just the early chapters. Read on and there are other things - many true, but as far as I know, many unpopular and/or untested.
Like many great works, Brook's discription of the problem is excellent, but his attempts to solve it are not all perfect. Thus, I would not hand it to a manager to read without some preface to it.
____________________________________________
a war on terrorism? How can we end a war on a method?
I read this in college for software engineering and even on our 4-8 person projects it made sense. In the corporate world, it makes more sense, but no one really listens. The same pressures of time and budget seem to outweigh the lessons learned from Mr. Brooks.
I saw a great explanation of WHY you get less per man on a large project than a small one, and why hierarchical organization seems to be necessary on projects with large numbers of people but can be dispensed with on tiny ones.
Imagine each person as a device with four "ports" (each representing a fraction of his time and/or attention). Each "port" can be used for communicating with one other person or doing one unit of work.
On a one-person project all the ports are used for work. You get four units of work done per day.
On a two-person project each person has one port used for communicating with the other and three for doing work. You get six units of work done per day.
On a three-person (non-hierarchical) project, each person has TWO ports tied up communicating, and TWO for doing work. Again you get six units of work done per day.
On a four-person (non-hirearchical) project, each person has THREE ports tied up in communication, and only ONE left for work. Now you're down to FOUR units of work per day - same as a single hacker in a closet.
On a five-person (non-hierarchical) project, each person has all four ports tied up with communicating. Nothing gets done. B-)
Of course you can to a limited extent increase the number of "ports" by tools to improve communication, or by overtime. And some people are better at switching tasks or communicate quickly, and thus have more "ports". But the same basic idea applies.
You can go beyond a handful of people and retain some productivity by restricting the interpersonal communication paths - to keep people from using up job-time communicating with others when it's not job-related. This tends to lead to specialization, with some people only communicating. That leads to a tree organization, with the "leaves" being people who actually do some work on the code proper, communicating only with one or two neighboring leaves, and others just communicating - and deciding what messages to forward.
And of course this leads to all the classical pathologies of hierarchies: Distortion of messages by multiple hops. Much decision-making must be done in the tree (and often far from the relevant data) to prevent saturating the communication links. "Leaves" are data-starved and must follow the decisions of "non-leaf nodes" or the project becomes disorganized. So the non-leaves become authorities and run the show.
To do large projects without such explicit communication hierarchies controling the workers you need to divide it into modules done by standalone groups, plus assemblies also done by standalone groups. The standalone groups must be redundant (so that at least ONE of the groups doing each particular thing gets it to work adequately.) Then the hierarchy is still there, but in the form of the invisible hand of evolutionary/market forces: Leaf modules are adopted or rejected by the assembly-constructing group constituting the next level up the hierarchy toward the root of the overall project, assemblies are adopted or rejected by larger-assembly groups, and so on. (Of course there can ALSO be more than one root, and users of the resulting product can replace modules or assemblies with others that do the job if they car to do so.) Each group can be flat or hierarchical, according to their own leanings (and the needs of their task).
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
What the fuck is "interesting" about this post? Some moronic undergrad took a class where his professor kept mistaking a book title? WHO GIVES A SHIT?!?!?
What the fuck is interesting about this post? "Lessons to teach"? Like what? This jackass doesn't bother to offer even one example. "Go read it." Gosh, thanks. May as well mod this half-assed post "+1 Informative." Idiot moderators.
Someone every year writes about the mythical man-month, and how things have changed. I can't believe /. even ran this article.
Put another way, 9 women can't make a baby in 1 month.
Some years back [...] I noticed a (partially emptied) case of the books in the IT manager's office. ([...] He'd already passed them out to everyone on his team.)
Sounds like a good man to work for.
On the other hand, if anyone in upper management EVER starts enthusing about _Crossing the Chasm_, start your next-job hunt IMMEDIATELY and QUIT as soon as you find a good replacement! Do NOT wait for your stock options to vest (they will soon be worthless) and start unloading the ones that have already vested.
_CtC_'s central message is hidden in a line near the end of one of the last chapters. It is: "Screw the early-hires with the big option plans. Only the founders and management deserve the big bucks. The early hires were necessary at the start, but now are overpaid and a drag on the bottom line. They are compulsive drones who have no power to fight you. This action won't even hurt you NEXT time around, because they are obsessed and will be early hires again at the NEXT company. You MUST do this to make your company stable for the long term."
The net result is that the pointy-haired executives, soon after discovering this book, dump the early hires. (And even if the author HAD been right, they do it too soon.) The early hires are the ones who actually had the skills and knowlege, and applied the hard work, to make the founders' hairbrained scheme WORK. As a result they are the repository of the internal knowlege of HOW it works. By dumping them without extracting this knowlege the execs kill maintainence and follow-on, and thus doom the company - starting in a couple years.
Of course by then they've moved on, so the NEXT set of upper management inherets the collapsing house of cards. But meanwhile the people who actually implemented the product are dispersed, and their stock is worthless.
So as soon as you see this infection taking hold, liquidate, cut your losses, and move on.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Since one human year equals seven dog years, couldn't we save time while keeping the team size small by hiring dogs as developers?
Yes.
But the result of such a project would be a real bitch.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
For example, he says, "Build one to throw away." Amen to that.
But never build TWO to throw away. If you don't learn enough from the first one to make the second one right, you'll never stop looping and deliver a product.
Development is not the letter "O". It's the letter "Q". You can loop a LITTLE, but eventually you have to deliver and move on.
Try to get it right the first time. Get it right the second.
Successful software development is like growing a perfect crystal. You're constantly diddling the additions to get the atoms lined up with no flaws. But once they're right you move on to the next layer. Build it, test it, fix it, test it again, loop till it passes, then LEAVE IT ALONE and MOVE ON.
(If you tested it as you went, the ONLY parts you'll EVER have to go back and change are the ones where you either didn't understand the spec or the spec changed.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
That's apart from the naturally rosy estimates of one's one programming/system admin abilities, versus a sober understanding of the full complexity of a project.
Part of the problem with estimating is that it's easy to only think about the time spent on the part you already KNOW how to do, and hard to even imagine the part you DON'T know how to do yet.
(My rule of thumb is to multiply the time I THINK it will take by three - because the part I have to learn on the way and can't visulalize now usually takes up two-thirds of the total project time.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Brooks explicitly deals with the subject of communication. He points out that time spent on communication grows exponentially with the team size. This means that at a certain point adding people will actually decrease the amount of available work time and therefore increase the development time.
What luxury! At least "head" refers to a part of the body. Here we're called "resources".
I really like the comparisons that are made between Software Engineering and Chemical Engineering when he revisits the MMM years later(Chapter 19). In discussing software engineering as an engineering discipline: He may be right that the field will never develop into an engineering discipline with as precise and all-encompassing a mathematical base as electrical engineering has. After all, software engineering, like chemical engineering, is concerned with the nonlinear problems of scaling up into industrial-scale processes, and like industrial engineering, it is permanently confounded by the complexities of human behavior
Oh, to have a workgroup server with only 15 people on it!
Unfortunately, we regularly have to use a server with about 50 users. Ouch!!!
'Course, I often use my laptop (linux) when the job-of-the-day does not require propietary tools which only work on The Great and "Mighty" Server.
Yes, most places use PCs or individual workstations, but you'd be surprised.
Yow! I'm supposed to have a plan?
Imagine each person as a device with four "inputs" (each representing a fraction of his total pleasure power). Each "input" can be used for pleasuring one other person or doing one unit of cum.
On a one-person jink all the inputs are used for himslef. You get all kinds of weird shit put in there every day.
On a two-person jink each person has one input used for pleasuring the other and three for the insertion of toys. You get six loads done per day.
On a three-person party, each person has TWO inputs tied up plesuring, and TWO for doing himself. Again you get six loads done per day.
While working as a tech testing RADAR receivers for Westinghouse, I read this book. The machine in question was the 32 bit upgrade for 16 bit minicomputers sold by Data General at the time (1986?). I ended up working with the machine later as part of a test-only test set due to the fact that the differences between the machines were extreme enough that a floating-point processor was never developed. The development environment was of such poor quality that one young EE (after fighting with the software for months) quit in disgust. Because there was no floating point unit the 16 bit machines were able to test a module in 3/4 of the time required by the newer model. This and the availability of '486 class micro's killed the market for similar DG machines. While the older machines could be coded in Fortran and was capable of decent hardware floating point, the newer machine used a restrictive Pascal compiler of the day - not something you really want for scientific/engineering applications as all of the heavy lifting had already been done in the wrong programming language. Trying to rewrite the code to provide more than test capability - troubleshooting and options for test - required more than one guy at a console part-time and the company didn't replace the outbound engineer with a repacement. The test-set IIRC was owned by the Air Force anyhow.
No sig in hell.
bob@Osprey:~>
The author points out the apparent inefficiencies in Brooks's surgical development model, but he seems to miss the logic behind it. Brooks notes that there's at least an order of magnitude difference between an employable programmer and a really good programmer. His well-informed suggestion for the ad-hoc development methods of the time was that an organization with 200 programmers, managed by the 20 best, should fire the other 180 and put the 20 back to work. Of course, if those 20 programmers have the other 180 backing them up, doing things like building tools, testing, researching language constructs and data structures and the like which will improve certain critical bottlenecks, they, the "surgeons", can keep focused on actually writing the bulk of the code that makes it into the finished product.
Certainly many of the criticisms were well-supported, but I think the author missed the background on this one.
WARNING: there is a trojan on your
Holy God do I ever want to introduce that smarmy reviewer's reproductive organs to my steel and leather shod foot.
What a self-loving asshole.
"Fred wrote in a time where systems were smaller and slower, where capacity was expensive.
So I'll mock that, and ignore the fact that he contributed more to our world than I'll ever even review."
Writers imply. Readers infer.
for my next project. Anyone who really thinks that "it didn't say anything that anybody with a couple years of software engineering experience didn't already know." is in dire need of a recto-cranial inversion.
I've worked in the field since 1974 (IBM/360) til today (Mac G4) and I can count on the fingers of one foot the number of designers, programmers, engineers and architects who wouldn't benefit from a bi-annual re-reading of TMMM. Perhaps you believe that you are the 2nd coming of Brian Kernighan, but in my NSH opinion, you are a real danger to any serious software project (as opposed to the 50-500 line "programs" you write in school)
John
Unfortunately still true. Every novice programmer starts out thinking they're better than anyone else and will be able to get stuff right the first time. Over time they learn that they're wrong. Whether the second version is done as part of the same project (or job) or a different one, whether it's superficially similar or just similar in its internal design, there will be a second version. If you're good a majority of the lines of code in the second version will be recycled from the first, but it's practically a guarantee that the major conceptual structures will be different. Get used to it. Learn to use it to your advantage. People who continue to deny it spend their careers either doing trivial things or doing more serious ones in a totally half-assed way. If you want to get good at building something besides toys, learn how to build on past experience.
Slashdot - News for Herds. Stuff that Splatters.