This is the inaugural edition of Code Reads, a weekly discussion of some of the central essays, documents and texts in the history of software. This week we’re talking about Frederick Brooks’s The Mythical Man-Month. (OK, let’s be honest: I’m talking about it. I’m hoping you, or you, or you, may want to, as well! If you don’t want to read my essay, you can just go straight to the comments and post something.)
Frederick Brooks’s The Mythical Man-Month came out in 1975, and I first heard its title later that decade. I’d already been a teenage programmer of sorts (of games in BASIC) for a few years, but I knew nothing of the world of large software projects that Brooks’ work addressed. I did know that the phrase “mythical man-month” grabbed my interest. It sounded less like the management-science term it was, more like a description of some prehistoric beast, heaving itself out of the primordial swamp to lumber across a desolate landscape.
Transmuting dry corporate-speak into evocative imagery? That was some trick.
When I finally did read Brooks’s book, more than two decades later, there, on its cover, were those beasts — struggling to pull their limbs free of the tar pit that served as Brooks’s starting metaphor for the awful dilemmas of software-project scheduling. By that time, I’d become more familiar with the sort of work Brooks’s book addressed. I’d knocked my head more than once against the wall of software development. And I found, as so many readers had before me, that this quarter-century old book anticipated and analyzed most of the problems I’d encountered — and even offered some useful advice on how to avoid them.
The Mythical Man-Month is best known for its formulation of Brooks’s Law: “Adding manpower to a late software project makes it later.” Software development isn’t like harvesting corn or carving widgets; since each project’s work is unique, when newcomers join up, the existing experts need to drop what they’re doing and orient the new recruits. And as the project’s roster grows, so too does the amount of time each participant has to devote to coordinating his work with a greater number of colleagues.
Brooks’s Law is so counter-intuitive that one still regularly encounters projects that ignore it, on the assumption that either (a) their particular undertaking is uniquely exempt from Brooksian limits or (b) the project employs some new methodology that invalidates Brooks’s principle. (One central argument of Eric Raymond’s “The Cathedral and the Bazaar” is that open-source methods combined with an efficient communications network like the Internet can overcome the logic of Brooks’s Law and allow the efficient deployment of swarms of developers in debugging efforts.)
But much more than Brooks’s Law awaits those developers who wish to go beyond the catchphrase level of familiarity with The Mythical Man-Month. The book introduces a whole slew of concepts at the heart of our understanding of how we build software:
- How do disastrously late projects get that way? “One day at a time.” (Brooks applied this phrase to the software field long before it became a 12-step self-help mantra.) Most slippage is the offspring of “termites, not tornados.”
- Sequential constraints: Some projects take an irreducible amount of time because one part of the task needs to be finished before the next can be begun — or, as Brooks puts it, “The bearing of a child takes nine months, no matter how many women are assigned.”
- Coding isn’t what takes the most time: Brooks’s rule of thumb is that actually writing the code takes 1/6 of a project’s time — with planning taking another third and the remaining half devoted to testing and debugging.
- Programmers vary wildly in individual productivity: Wildly as in the highly productive programmer may well be able to produce ten times more useful stuff, however you choose to measure it, than his colleague.
- The goal of “conceptual integrity” or unity of design: The best programs and software systems exhibit a sense of consistency and elegance, as if they are shaped by a single creative mind, even when they are in fact the product of many. The fiendish problem is less how to create that sense in the first place than in how to preserve it against all the other pressures that come to bear throughout the process of writing software.
- The “second system effect”: Brooks noted that an engineer or team will often make all the compromises necessary to ship their first product, then founder on the second. Throughout project number one, they stored up pet features and extras that they couldn’t squeeze into the original product, and told themselves, “We’ll do it right next time.” This “second system” is “the most dangerous a man ever designs.”
Brooks’s success in The Mythical Man-Month at defining the nature of the software-project beast depends, I think, on to two special characteristics of the work: its roots in Brooks’s personal story, and the power and clarity of its style.
The Mythical Man-Month traced its origins to Brooks’s experiences leading the team tasked with writing the IBM 360’s operating system — an unprecedently huge project that suffered legendary delays . At a 2004 event the Computer History Museum held marking the 40th anniversary of the birth of the IBM/360 project, Brooks recalled the book’s genesis:
When I was leaving IBM, Tom Watson Jr. and I had a very good conversation. He said, “You’ve managed the hardware part of the project, and you’ve managed the software part of the project. What is the difference, from a management point of view, between the hardware and the software? Why does software seem to be so much harder to manage?”
And I said, “Well, I can’t answer that on the spot, but I’ll think about it.” And it took five years.
I think it’s important, in reporting a development effort, to indicate what you tried that didn’t work as well as what you tried that did work. And the fact that I’d consider the OS/360 effort phenomenally successful doesn’t meant that I think that everything we did along the way was wise. We made some stupid blunders.
There’s an urgency to The Mythical Man-Month that makes it more immediate, and more satisfying, than most run-of-the-mill business books. Brooks emerged from the IBM project asking passionately, “Where did we screw up?” — and trying to record the answers for the benefit of futures toilers in code.
None of that would get Brooks very far, or have us reading him three decades later in this volatile field, without his unusual skill at expressing complex ideas: He is at once forthright and graceful. He draws just enough parallels from outside the field (a New Orleans restaurant menu, the Tower of Babel) to leaven the proceedings without ever sounding gimmicky. Even when he’s packing multiple polysyllables, his sentences flow with power:
Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.
And at times his eloquence waxes positively Elizabethan:
The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination.
Is The Mythical Man-Month dated? Some of it, sure. At one point, Brooks says, “I am convinced that interactive systems will never displace batch systems for many applications.” Oops. (Brooks graciously cops to this and some other mis-predictions in his retrospective postscript, “The Mythical Man-Month After 20 Years.”) Still, even such a cloudy-crystal-ball passage has some value today: it made me wonder about the times I’ve said, echoing other computer users of my generation, “I can’t ever see Web-based software entirely replacing desktop applications.” Such certainties could well prove as fleeting as Brooks’s confidence in batch mode.
The Mythical Man-Month also devotes many pages to discussions of the proper management of the five-foot-thick “project workbooks” of a bygone era. In the days before intranets and wikis and source-code repositories, these were the tools a team used to coordinate work. No one will shed a tear for the demise of fat binders. But today’s wheel-reinventers could probably benefit from an examination of how previous generations got their teams rolling in sync.
In other words, even in those passages where it’s showing its age, The Mythical Man-Month remains valuable. It’s a remarkably enduring work. It was the first book I turned to when I began my quest to understand why software is so hard, and I know I’ll keep returning to it. Anyone trying to create software is, as Brooks paints the picture, traversing a pit; The Mythical Man-Month offers us “boardwalks across the tar.”
Post Revisions:
- March 28, 2012 @ 10:52:48 [Current Revision] by Scott Rosenberg
- October 2, 2006 @ 07:49:34 by Scott Rosenberg
One note: The current edition of The Mythical Man-Month, called the “Anniversary Edition” (Addison Wesley brought it out in 1995 to mark the book’s 20-year milestone), includes the full original text and four additional chapters. These include Brooks’s well-known 1986 essay “No Silver Bullet” and a follow-on titled “No Silver Bullet Re-Fired.”
Together, the “Silver Bullet” essays present a hugely important argument about the nature of the software field in their own right. But they are somewhat separate from Man-Month itself, and I’d like to devote a whole separate discussion of Code Reads to them at a later date.
Brooks classic seems to keep coming back into the popular consciousness every few years, and I have to admit that I once spent a few minutes with it in the aisle of a mega book store and found its prose pretty clumsy and its generalizations annoying.
I have learned a lot since then, and the more years I spend in development, the truer his words seem. I had not realized that the very IBM system that Brooks developed was the same that I cut my teeth on when I learned RPG programming in the mid 80’s.
So I submitted this to Reddit. Hope it gets legs. Such an erudite essay deserves no less!
My original thought about The Mythical Man-Month, way back in the late ’80’s when I read it while in college (the first time) was that, as an apology for OS/360, it wasn’t apolgetic enough. (My experience with IBM systems, then and now, was pretty bad.)
Since then, I have had a lot of experience on a lot of failing projects (really—parts of my resume read like a list of major software disasters of the early ’90’s), and like almost everyone, I have come to the conclusion that Brooks is almost entirely correct. He nails the causes of most of the problems I have seen.
Unfortunately, I have also come to the conclusion that Brooks is almost entirely pointless. Everyone knows Brooks’ wisdom, including those who actually could make a difference, but no one does anything about them. The same people who happily quote, “you can’t get a baby in one month from 9 women,” continue to expect to do so.
And so, ultimately, I think Brooks’ book is a failure. It and a lot of similar literature are very well written and very entertaining, but at some point analysis seems to become onanism.
I wonder if your forthcoming book will address the Big Question: will programming always be this hard? Brooks is often cited by those who say yes, this is as good as it gets. Yet at the very end of his 20-year reappraisal Brooks sounds a note of optimism, suggesting that perhaps our discipline is just still immature.
The history of science and technology teaches that progress occurs in fits and starts, and that some societies seem to foster innovation, while others stagnate. One might then ask the politically charged question: does our lack of progress indicate some deep dysfunctions in our field?
Jonathan — that is indeed one of the big questions my book tackles. I can’t say I reach any definitive conclusion, but it does seem to me that the pressure in the software field to tackle new challenges means that the difficulty is, as Brooks says, essential and not accidental. If we were simply aiming to perfect a consistent set of applications — keep making word processors or databases better! — then it’s possible to imagine ironing the difficulty out of the undertaking. But not when every few years sees the creation of entirely new categories of use. The book’s discussion of this question forms its centerpiece in two chapters that depart from the main Chandler narrative to look at the histories of software methodologies and “Big Ideas” (or silver bullets) in the field.
Tommy — your post made me smile — I’ve certainly encountered my share of managers who expected to defy Brooks’s Law. I’ve even done it myself. I wonder if it’s fair to attribute that failure to Brooks, though. Is the writer who expresses a difficult truth responsible for his readers’ denial of reality?
Uh, so you’ve written a nice essay about TMMM and laid out some things, sort of in lecture mode. Where is the invitation to discuss anything, or are you expecting it to be self-generating?
I’m not clear there’s an invitation for a discussion here. Maybe the closest we have is around why is it that people continue to repeat the same thing over and over (adding people to a late project) expecting a different result?
I’ll second that. In the opening essay, it sounds like you’ve already decided what you think about The Mythical Man Month, which isn’t very open ended. What still puzzles you about it?
OK, Orcmid, Brian — busted! Point taken.
I’ve been an essayist, critic and columnist for decades now. Though I’ve also spent years in online discussions (since the early ’90s, pre-Web), “lecture mode” certainly is my default.
So this is a work-in-progress. This “MM-M” posting is my first try. Next time out I’ll see what I can do to be more open-ended.
In the meantime, Orcmid, your question’s a central one. Repeating your actions and “expecting a different result” is someone’s (whose?) famous definition of madness, right? I think some of the reasons people still “add manpower to late projects” thinking it will help are (a) they feel they have to do something and (b) everyone can find a reason that his or her particular project is exceptional in some way.
As for your good question, Brian: One thing that puzzles me about the book is why its central insight remains so poorly known out in the field. (I guess this is a variation of Orcmid’s question.) The book’s 30 years old, the software industry is no longer in its infancy, so much of the world’s business relies on the creation of software tools to power it; we haven’t succeeded yet in making the act of software development more dependable, yet we don’t seem to be paying close attention to the few reliable insights into the process that we do have in hand, like Brooks’s.
I first came across TMMM when I was browsing the library stacks 15 years ago, and came across a book with an interesting-sounding title that seemed to have my name on it!
One of the key lessons that I’ve had to learn in order for a lot of Brooks’s observations to be useful is simply this: dead reckoning for “how long will it take to write this code” is simply not a functional way of planning. The only way (for me, anyway) to get even a reasonable plan is to consciously and honestly collect data on how long projects take, and then use that data for the next. Honesty is an important thing here, because the tendency is to be optimistic, and say that the day of sitting staring at the code and writing very little “doesn’t count” — when, in reality, that day was spent collating all the things wrong with it, and was essential preparation for the day of refactoring that followed. And it’s tempting to say that the day of refactoring “doesn’t count”, because next time you’ll do it “right” the first time. And so it goes, for me at least.
Somewhere I came across a claim that IBM has a standard estimate for lines of code per programmer per day, and while I don’t remember the exact value, it was only double digits. Anyone have a source for that? Reading that was sort of a wakeup call for me.
I guess in some ways the seeds of that observation where in TMMM, in the sense that a lot of that time is the fact that it takes a while for me as a programmer to get up to speed on a new project, and that time needs to be accounted for. On the other hand — perhaps because it’s presented from a very different perspective (of large programming groups, and having exsiting projects to add people to rather than the other way around), or perhaps just because I didn’t read it when I needed to know it. It’s been a while since I’ve read the book, so I’d be interested in other people’s views on how much of this is there.
On a different note, I think there’s also an interesting study to be made of large open-source projects, and the whole Bazaar idea. In my experience, the bazaar is quite good for testing and small bug reports, and to some extent for maintaining and building existing packages, but I have seen very few projects (I can’t think of one, really) that didn’t start out as one person spending vast amounts of time to get it started and get at least a half-finished prototype working. And the GNU Fortran project is facing a bit of this now; there are maybe a half-dozen people who know enough to actively work on the core of the compiler at a bit-picture level.
I think the reason software is hard is not because of the wrong methodologies but for two reasons:
1) because computer systems are not built in a way to store information in a human-friendly way. By eliminating the problem of data (creating/deleting/modifying/querying), at least 50% of our problems with software will go away, and we will focus in the real interesting stuff i.e. what to do with the data, i.e the calculations that interest us.
2) software is not like Lego; we still do not assemble software from ready-made components as if we were building a Lego house. Almost every programmer has to write low level stuff like if blocks, for and while loops, opening and closing files, creating and deleting resources, thread synchronization etc.
I first read TMMM in the late 70’s, and still remain impressed with Brooks’ insights. Here are a few thoughts on why software development remains hard, based on my own 30+ years in the field (working in a mixture of academic, commercial, and industrial environments).
There’s a well-known management saying that, “You can’t manage what you can’t measure.” In contrast, Brooks drew a (correct) analogy between software developers and poets. Many organizations (and managers) don’t want poets; they want factory workers whose actions can be predicted and measured (and understood by those who don’t do the work). Therefore the things that get measured and rewarded are sometimes things that don’t help developers do the (real) creative work: lines of code (LOC), attendance at meetings, presentations full of bullet-lists and marketing-speak.
Dijkstra observed that LOC is meaningless, except that managers can measure it. He went on to say that, understood correctly, it is often counted “on the wrong side of the ledger”. Corporate programmers aren’t really supposed to produce LOC. They are supposed to produce solutions to problems. LOC are what programmers *spend* in order to produce solutions. A programmer who gets the job done with less code is usually *more* productive than one who spends large amounts of code (especially in the long-term view, where more LOC translates into more bugs and more maintenance effort).
Developers who’ve worked on large projects (but taken a think-first approach) are familiar with the phenomenon in which there’s initially little externally-visible progress, but then a critical mass is achieved and things appear to move with incredible speed. The later rapid production of results is crucially dependent on the original thought processes, in which the developers seemed to be wasting time exploring alternatives, or just sitting and thinking.
A related factor is contemporary short-attention-span culture. It is a truism that investing for the long term is a better strategy than looking for the quick payback. Yet we still have day-traders and Enron/WorldCom scandals. Why? Because people continue to choose immediate gratification over sustainable benefit. In the software development field, as with other large-scale human endeavors, taking the quick-and-dirty approach gives the illusion of rapid progress. However, the dirt accumulates, which brings me to my last point.
Most software development is large organizations is involved with maintaining, extending, or integrating existing software. It is a lucky programmer who gets to do a start-from-scratch project with no legacy constraints. But that means that all of the accumulated dirt from the previous cycles is now a burden on the current project, in addition to whatever actual problem is being solved.
A working developer who is told, “Be creative!”, “Think outside the box!”, “Make it better!”, and then, “Oh, by the way, it has to be compatible with all the existing stuff.” knows instantly that (s)he has been handed an impossible task. But (s)he also knows that the only aspect which will actually be measured is legacy compatibility. In the face of a user/customer complaint or a legacy interface glitch, the effort put into infrastructure improvement, creative and effective use of resources, built-in future flexibility, etc. disappear from the radar screen.
Why does software development remain so difficult? Because it is done by human beings managed by human beings in organizations full of human beings. Why are we surprised when software development suffers from the same problems of poor communication, mixed agendas, short-sighted decisions, etc. that are so well-known in other areas of human endeavor?
There’s another point Brooks makes that tends to get lost in reviews; Programmer productivity increases as the level of language abstraction is raised.
That is, humans have a fixed-size buffer to work with, so filling the slots with small concepts (IF statements, loops, assignment) causes pipeline stalls. Higher level abstractions (functions, objects, modules) keep the thought process moving and cover more ground in fewer cycles. He includes some discussion of this point along with a few studies to support it.
Scott,
What evidence do you have that software development is no longer in it’s infancy?
I know of no such evidence. I’d certainly like it to be true, but I wonder. Perhaps it’s just our collective ego that leads to that assumption?
Jim
Jim, Infancy is a vague word; some people might say that accounting was in its infancy until the invention of the spreadsheet, although its been around for hundreds (thousands?) of years.
A craft is no longer in its infancy when its skills are widely replicated and its results are competent. I just took a trip to Scotland in which everything from my airline tickets to my hotel room key were software-based. The G8 countries are largely run by software now. And software development is a craft done by around five million people in the US, sharing a culture of terms and development techniques.
However I would agree that software development will retain a “youthful” edge for many decades, because the underlying hardware environments keep changing so drastically.
Jim, I guess I was applying the analogy of a human lifespan. If we think of programming as a field that had its infancy in the 50s, its childhood in the 60s, its difficult adolescence during the “software crisis” of the late 60s, and so on, it is now well into middle age or late middle age. It’s an aging boomer! Retirement looms.
Obviously that analogy is arbitrary — you could as easily say that the first 50 years of programming history represent a mere year or two in the growth cycle of the field. 50 “programming years” might equal a mere single “human being year.” All sorts of other analogies spring to mind. But “an individual lifetime” is the one I was, perhaps a little carelessly, thinking of.
Joel, you asked, “Why are we surprised when software development suffers from the same problems of poor communication, mixed agendas, short-sighted decisions, etc. that are so well-known in other areas of human endeavor?”
I guess my answer is, I’m not surprised when software development suffers from the *same* problems. But I’m curious about why it so often seems to suffer from considerably worse problems.
I’m delighted, and being further educated by, these posts. Thanks to everyone! Later tonight I’ll be opening a thread on the Dijkstra paper, “Go To Statement Considered Harmful.” But there’s no reason to stop here if there’s more to say. We can and will be multithreaded…
One reason for repeating the same mistakes is that it’s not the same people making them. You might as well ask why we never seem to learn that a house remodelling can cost far more than expected. Maybe the real question is how to better train people in project management?
Scott, I’m not really sure that the problems of software *are* “considerably worse problems” than those of comparable efforts. Here’s a line of thinking due to EWD, slightly updated for the times.
Using round number to make the arithmetic easier, say that my computer operates at 2GHz. I have often run programs whose time to complete an action is of the order of five minutes, which is 300 seconds, which is 600,000,000,000 cycles.
Google Maps tells me that I can drive from Boston, MA to Seattle, WA in a little over 3,000 miles, which is 15,840,000 feet, which is 190,080,000 inches.
If my five-minute task is a drive from Boston to Seattle, then one cycle of my CPU is 0.0003168 in, or 0.000804672 cm. According to data from Wikipedia [http://en.wikipedia.org/wiki/Orders_of_magnitude_(length)] the width of a human blood cell is about 0.0001 cm. So (if I haven’t dropped a decimal somewhere ;-) assembling my five-minute computation out of CPU cycles compares to assembling a trip from Boston to Seattle out of steps equal in size to a few blood cells.
Put another way, if I use steps of one inch, then assembling a comparable number of steps gets me more than 380 times around the earth at the equator.
OK, to be fair, programmers don’t build programs by hand-assembling CPU cycles. But the point of the exercise is to recognize that running pieces of software are incredibly complex beasts built of incredibly tiny parts. And if any of those parts goes wrong, there’s a problem. How many other human artifacts have that span of scale? And how many other human artifacts (of even vaguely comparable spans) are free of chronic problems? Governments? Highway systems? Economies? Corporations? Political parties?
Software is hard because all huge efforts requiring coordination are hard. Even more so when the artifact is invisible (which lulls us into forgetting how big it is).
Even more so when it is incredibly pliable. One can’t shift an interstate ramp over by just a few feet, or turn a knob and boost consumer confidence. But a few keystrokes can radically alter the performance of the most complex program. Physical systems have inertia which physically prevents us from changing their state rapidly. But in software development, we do it all the time.
It reminds me of the old joke about the talking dog; what is remarkable is not his pronounciation problems, but the fact that he succeeds at all!
I have read first 3 chapters of the book and was amazed to find that it still holds good. Unfortunately i wasn’t able to continue, but after reading your essay i would definetly like to continue where i had left.
I’ve read TMMM several times over the past 20+ years of software development and each time I re-learn the following lesson: I’m a master at not paying attention to my lived experience. And as a result, I just forget what didn’t go well last time, and repeat that behavior again. But enough about me!
I think that Brooks’ insights are ignored for a couple of reasons. First, as others have mentioned, software development requires a certain optimism, and most of us prefer to assume that, this time, things will go well, or at least better than the last time. So it’s easy, and only human, to repress the problems of yesterday. It takes some courage to remind oneself and one’s colleagues of past mistakes in judgement and knowledge. But if we’re going to get better at software development we need to get over being defensive, and really learn from experience, even if that makes us look like rookies.
And second, my experience of software and technology in business is that it is a field that ignores its elders. Or put another way, technology is a young person’s game. But even if (mostly) young people do new things with the newest technology, that’s not a reason to ignore what’s already been learned about software systems design and engineering. There isn’t going to be much development of a discipline of software engineering without learning from experience. So one question is How do we build working relationships between the younger and older developers, engineers, inventors, …?
Bill: I guess human memory can have a sort of half-life decay entirely unknown to computer memory (absent hardware failure)! I think you’re right that the field sometimes “ignores its elders” — one of the motivations behind this Code Reads project is to make a modest effort at directing some attention back over the literature of the field’s past.
Joel: You write that you’re not sure that software’s problems are any worse than comparable efforts in other fields — but then you do a great job of outlining some central factors that (to me) explain why its problems are indeed worse: software’s complexity, fragility, invisibility, pliability… each of these is a factor that Brooks touches on, and each, it seems to me, represents an area in which the field has made only slow and modest progress since the time of his writing.
Ian and Scott – good answers concerning the use of “infancy”. I posed the question mostly as a provacation to think about the analogy between a human life cycle and software. I’m just not sure it’s a good one, despite it constant use.
And, like Joel, I’m not convinced that the problems of software are considerably worse than human problems. Do software projects fail more often than small businesses or marriages? My first thought is no.
I’m an optimist, but I have a lot longer time-frame in mind than most. I think we’re gradually building a supporting infrastructure of common vocabularies, processes, and software capabilities. We collectively get better by constantly pushing, and the greatest asset is a high tolerance for frustration. I think it will take several more generations. That’s human generations.
Bill, I would agree that we don’t listen much to our elders, but I think we generally end up using their tools (sometimes after they’ve been rewritten in the language-de-jour).
Jim
Jim, well copying is the sincerest form of flattery, so reusing older tools is often a good thing. But a good deal of what was learned, through painful experience, about how engineer robust and reliable code, is being re-learned today. Consider, for example, the discussions about the value of documentation and comments in code. With respect to the code, very often the existing comments refer to earlier versions. So when I was reviewing a colleague’s algorithm implementation he told me to read the code and ignore the comment. But what do I look at to learn why this algorithm was coded in the first place? The code won’t help me here. I need to know the purpose and role that the program plays in the user’s world and work. Where is that context described?
So, when I get involved, once again, in conversations about how the code is self-documenting, I realize that we haven’t learned anything from the efforts of the 1960’s, 70’s, and ’80s, about the scope of the problem of building robust software systems we can rely on.
I worry that we’re moving forward with tools, but backwards in engineering and architectural competency. Does everything need to be re-learned from experience? Can we learn from the past?
I’m not trying to be facetious. I think these are serious, empirical questions.
There are economic and political reasons for not being able to benefit from past experience. First of all, the IT industry is not a single organism, it is the sum of its parts, and most often those parts do not communicate at all. Secondly, big corporations like Microsoft and Sun are not aiming at ‘state of the art’, but at expanding their marketshare and profit, so advancements in programming languages that usually take place in research centers and academia do not propagate to the IT industry.
I’ve read this book twice, and I realized that there were some stuff I haven’t grasped the first time. I’ll read it again, and I know there’s going to be something new to learn from it. It’s one kind of a book that challenges you every time you read it. One thing that challenges me is Brooks’ proposition on No Silver Bullet. Even now with all these new technologies, languages, frameworks, etc., I still have to remind myself that there are actually no silver bullets, and probably never will…even though XML feels so ‘good’ to say…XML…what’s next? SOA feels good too…
I’ve never worked for a pure software development company but I have done application development for companies whose primary business was in other industries. When I read TMMM for the first time about a year ago, the thing that struck me is that Brooks was right on but his observations did not persist in the industry for 2 reasons (based on my personal experience).
Paradigm shifts lead many to think they needed to reinvent the wheel and, in the process (yes, I realize I’m mixing my metaphors), throw out the baby with the bath water. As an old IBM mainframe programmer newly hired by a company making the shift to client-server in the 90’s, I was amazed that they were all of sudden uninterested in things like source control, development methodologies, coding standards, QA, etc. The thinking seemed to be that this sort of infrastructure was a mainframe concept and didn’t fit in with the new paradigm. The company is in the process even today of trying to build in infrastructure and solid project management after the fact. I think of it as trying to pour the foundation after the house it built.
The other reason I think we’ve not held to Brooks’ rede is that IT, especially outside of the pure software development industry, is managed by non-IT managers. I’ve seen accountants and others in CIO slots all too often. When they’re willing to listen to the IT specialists that work for them, it can be a productive partnership but they’re all too often distrustful of those specialists. Many CIO’s don’t really seem to understand the process of software development and they’ve never heard of Brooks’ Law. If you’re an accountant charged with cost cutting, you don’t want to hear analogies about poets and pregnant women. You want to know how many programmer units it takes to get the job done so that you can figure those units into your budget. The notion that programmer A’s hour is rarely equal to programmer B’s hour is enough to make you tear your hair out.
Scott, I agree with the assessment that in the years to come incremental development will become the norm; it must become the norm if the industry wants to remain important.
I think one of the reasons why the software industry fails to fully understand the Brooksian theorem is that software is so pliable that it is _easy_ to believe seriously that the best solution can be produced _easily_, that software is the _heart_ of the system and therefore _has_ to be a single production. i.e. at the heart of the developer’s automatic attitude lies such grandiose assumption, and of course the nemesis… A dam, highway, railroad, television receiver, cpu, political party or a business is never designed and produced with such attitude. These works are no less critical in their contexts yet in every case the developer goes about the production with a definition and discipline of value accretion. The virtual nature of software makes it hard to get real.
The very real Moore’s Law could be making the problem exponentially worse.
One solution to this problem might be for the software consumer and producer to use time and money metrics in defining the value of the product, instead of only time or only money, or worse leaving it to ‘convention/standard/expert’. The consumer ought to speak in terms of times and monies, if the software business is to see any improvement, I think.
l am a chinese, l’m hitting on the book, l have viewed the comments all readers left, l just found some part really counts but some off the point, we can’t be so fussy, in deed, the sofrware market gets more and more commercial, anyhow, it’s the trend of times, we shall be much objective when dealingwith the contention. havea good time, l am leaving the mesage in Beijin of China
The Mythical Man Month, and Brook’s Law are really just the catch phrases of this seminal writing. The crux of the book is about how to achieve conceptional integrity through a clear and decisive separation of interface and implementation, and incremental development pratices (grown, not built). I’m amazed after reading “The Pragmatic Programmer”, how much can be traced back to TMMM. Brook’s doesn’t mention “Write it Once”, or DRY, but the seeds are definitely there.
The key point of Brooks’ book is that it isn’t about the software; it’s about the management (and conduct) of software development. The problems Brooks’ identifies are generally the problems of any significant project. The book isn’t aimed at programmers, it’s aimed at managers. Someone in the comment string noted that software development isn’t about the software, it’s about the business problems that software systems or applications will solve. So it might be useful to consider how TMMM addresses how people manage the business problem-solving exercise rather than “software development” and factor that into future project management. My experience tells me that all projects need key things: understanding of the problem (s), desired solutions (aka requirements), QA, CM, plans, validation, etc. Software development isn’t unique compared to other projects, but it’s the solution space we work in. If project teams spent as much time on peer reviews of requirements (in whatever form), interfaces, and integration as they do in testing, then testing and the resultant debugging would become asymptotic to zero in the level of effort and time needed. It ain’t about the software!
While programming in COBOL and Assembler in 1969-71 at a Military installation we found that we produced 3 lines of COBOL code per day. We got this by just dividing the number of lines in the finished product by the number of man-days spent. Assembler: 100 lines per day. And we felt that one line of COBOL contained very roughly the functionality of 33 lines of Assembler code.
Our conclusion was that using a higher-level language didn’t really increase our “functional” output per day.