Status
Available
Call number
Library's review
Indeholder "Preface", "Chapter 1. The Tar Pit", "Chapter 2. The Mythical Man-Month", "Chapter 3. The Surgical Team", "Chapter 4. Aristocracy, Democracy, and System Design", "Chapter 5. The Second-System Effect", "Chapter 6. Passing the Word", "Chapter 7. Why Did the Tower of Babel Fail?", "Chapter
Bogen behandler en række klassiske emner, der er blevet klassiske, blandt andet fordi denne bog behandler dem. Titlen henviser til at en mandmåned er en farlig enhed at regne i. Programmering af store systemer betragtes som en tjærepøl, som man har brug for al mulig hjælp til at undslippe. Denne bog giver en hjælpemidler og visdom nok til at genkende andre hjælpemidler.
Her i 2020 er den danske boghandlerkæde Arnold Busck lige gået konkurs og et fejlslagent it-projekt har fået en stor del af skylden.
Fremragende bog!
Show More
8. Calling the Shot", "Chapter 9. Ten Pounds in a Five-Pound Sack", "Chapter 10. The Documentary Hypothesis", "Chapter 11. Plan to Throw One Away", "Chapter 12. Sharp Tools", "Chapter 13. The Whole and the Parts", "Chapter 14. Hatching a Catastrophe", "Chapter 15. The Other Face", "Epilogue", "Notes and references", "Index".Bogen behandler en række klassiske emner, der er blevet klassiske, blandt andet fordi denne bog behandler dem. Titlen henviser til at en mandmåned er en farlig enhed at regne i. Programmering af store systemer betragtes som en tjærepøl, som man har brug for al mulig hjælp til at undslippe. Denne bog giver en hjælpemidler og visdom nok til at genkende andre hjælpemidler.
Her i 2020 er den danske boghandlerkæde Arnold Busck lige gået konkurs og et fejlslagent it-projekt har fået en stor del af skylden.
Fremragende bog!
Show Less
Publication
Reading, Mass.: Addison-Wesley Pub. Co., 1995. xiii, 322 p. : ill. ; 24 cm. Anniversary ed.
Description
These essays draw from Brooks' experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice. -- from publisher description.
User reviews
LibraryThing member jjmcgaffey
Eh. Very interesting and potentially useful concepts - at least, if I were planning or managing a major software project. But as soon as he gets down to details, it turns into a mildly interesting discussion of computer history. When he spends an entire chapter (well, nearly) on the advantages of
Show More
time-sharing terminals as opposed to batch debugging...yeah. Not really helpful in terms of what we've got now. The final chapter - the update, as of 1995 - is more interesting but still outdated - he spends a lot of time talking about this wonderful new thing, object-oriented programming. Which is useful, in exactly the ways he discusses - but it's also the way I learned programming in college, so he doesn't have much he can teach me. The most interesting part, actually, was when he pointed out that about then, the 1990s, there had been a major switch in programming - it went from basically all custom-built programs, designed from the ground up for one particular company and usage, to what he calls "shrink-wrapped" packages like Excel and FoxPro, where the program is built to be general-use with thousands or millions of users each working with it slightly differently. It does make a major change in considering the programming process - the specification of the program get both looser (because they don't have to match one client's specific needs) and tighter (because they have to be useful in a whole lot of different situations). The cost variable does too - if you're spending thousands of man-hours on one program for one client, it's a couple hundred thousand dollars minimum to make it worthwhile. If you spend those same thousands of man-hours on one program that will be bought over and over and over by different clients, each one can be quite cheap. I wonder if MS Office pricing is a remnant of the older cost structure? It's not thousands of dollars, but it's pretty pricy for what you get. Anyway - the point is, by the time I was paying attention to commercial programming, shrink-wrapped was the norm and custom was that weird way government and a few retro companies insisted on getting software. I really hadn't realized that it had ever been another way. So - I learned some things, the history was interesting, but that's a read-once. The concepts might have been useful, but the illustrations used are so out of date that I can't apply them to anything I'll actually do. So, as far as I'm concerned, no longer a particularly useful book. Glad I read it, don't need to (ever) reread. Show Less
LibraryThing member szarka
Although much of the approach Brooks advocates has been common practice in the software industry in the 30 years since the book's publication, The Mythical Man-Month remains as relevant today as when it was written. It references obsolete platforms like System/360 and Multics, and is set in a world
This book ought to be assigned in every introductory programming course, so students will better understand why they're being asked to create modularized, self-documenting code. The burden of the extra reading will be offset by their relief at not being required to flow chart their programs!
[2006-07-24]
Show More
where punch cards and PL/I were state-of-the-art, but human nature hasn't changed. The few parts that are truly irrelevant remain charming, like this comment: "The Apostle Peter said of new Gentile converts and the Jewish law, 'Why lay a load on their backs which neither our ancestors nor we ourselves were able to carry?' I would say the same about new programmers and the obsolete practice of flow charting."This book ought to be assigned in every introductory programming course, so students will better understand why they're being asked to create modularized, self-documenting code. The burden of the extra reading will be offset by their relief at not being required to flow chart their programs!
[2006-07-24]
Show Less
LibraryThing member BrianDewey
Brooks, Frederick P.. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1995. A classic. This was a valuable education for me; I had the belief that shipping software is primarily about writing and testing code. Wrong! Brooks does a great job at explaining why developing
Show More
software is hard: the need for conceptual integrity, to resist the urge to tinker, and handle the human element of software. Show Less
LibraryThing member alspray
A book about technology, first written in 1975 and yet still - astoundingly - relevant.
Imagine reading along, mentally applying the lessons to your own experience when the author notes that great efficiencies would be gained if only everyone had a desktop computer... my god! This book is ancient
And that's what is both instructive and disturbing - the I.T. field is still struggling with the same issues they struggled with a quarter century ago.
That aside, Brooks does a a fantastic job of discussing how software "is done", the contributions of each role on the team and how things get very complex very quickly as the size of the project scales up. His insights remain poignant and his credibility increases as many of his predictions from 1975 ring true today.
And while Brooks does talk about ease of use and how important it is that the application meets the needs of the people who use it, he never mentions the role of the Usability Practitioner. Is this an oversight or an active decision or was there simply no such thing as a Usability Practitioner in 1975? I would have expected him to note the role in one of his many follow-up chapters.
Speaking of which, my only critique is with the structure of the book. Brooks has returned over the years to add follow-up chapters such that its hard to distinguish what is the end of the original book and what was added later.
Wisdom is a hard thing to come by. You gain it slowly by experiencing life yourself or maybe a little faster by learning from others experience. As someone working in the field of software development its incredibly helpful to be able to differentiate temporal issues from an issue that is simply innate to the work we do. I feel I'm all the wiser for the read and I wish Mythical Man Month were required reading for my colleagues
Imagine reading along, mentally applying the lessons to your own experience when the author notes that great efficiencies would be gained if only everyone had a desktop computer... my god! This book is ancient
Show More
(in terms of technology)!And that's what is both instructive and disturbing - the I.T. field is still struggling with the same issues they struggled with a quarter century ago.
That aside, Brooks does a a fantastic job of discussing how software "is done", the contributions of each role on the team and how things get very complex very quickly as the size of the project scales up. His insights remain poignant and his credibility increases as many of his predictions from 1975 ring true today.
And while Brooks does talk about ease of use and how important it is that the application meets the needs of the people who use it, he never mentions the role of the Usability Practitioner. Is this an oversight or an active decision or was there simply no such thing as a Usability Practitioner in 1975? I would have expected him to note the role in one of his many follow-up chapters.
Speaking of which, my only critique is with the structure of the book. Brooks has returned over the years to add follow-up chapters such that its hard to distinguish what is the end of the original book and what was added later.
Wisdom is a hard thing to come by. You gain it slowly by experiencing life yourself or maybe a little faster by learning from others experience. As someone working in the field of software development its incredibly helpful to be able to differentiate temporal issues from an issue that is simply innate to the work we do. I feel I'm all the wiser for the read and I wish Mythical Man Month were required reading for my colleagues
Show Less
LibraryThing member colinangusmackay
While some may say this book is out dated there are still important lessons to be learned from it. I feel, however, that because the examples given to back up the arguments are now out of date it may make reading the book difficult for those who were not around at the time the original edition was
Show More
published. Show Less
LibraryThing member Lyndatrue
Often, a book such as this, which is ground-breaking at the time of publication, loses much on its way through time. This work is still timely, and the lessons (sadly) still need to be learned. My favorite of anything Dr Brooks said:
"Nine women can't make a baby in one month."
The chapter entitled
This is not just a historical book; it's still useful, and I recommend it.
"Nine women can't make a baby in one month."
The chapter entitled
Show More
"Why Did the Tower of Babel Fail?" has the most instructive and useful discussion I've seen on how to manage a large programming (or other) project. It's brief, to the point, and leaves nothing out.This is not just a historical book; it's still useful, and I recommend it.
Show Less
LibraryThing member samwilson.id.au
I especially enjoy Brooks' discussion about the effort that goes into the 'productization' (i.e. packaging etc.; pretty much all non-coding work) of software.
LibraryThing member tjbond
An excellent book on management and software development. It is remarkable how much Brooks gets right.
LibraryThing member RobKohr
The major important concept of the book is the downward curve in productivity per worker as additional employees are added to the project.
The book goes through a lot to prove this and give some reasons for it (for example more permutations of communcation connections between employees).
The down
The book goes through a lot to prove this and give some reasons for it (for example more permutations of communcation connections between employees).
The down
Show More
side is that there is just too much outdated material in this book to make it worth reading. If you fully grasp the above concepts, skip this book, otherwise you will be bored to tears. If you don't grasp these concepts, then read the book as it is the best place to start on the subject. Show Less
LibraryThing member jcopenha
Wow. If you missed my blog entry you should definitly read "No Silver Bullet" if you read nothing else out of this book. I can see where this book is considered a "classic". The ideas expressed have since been expounded upon with a multitude of books covering a single essay. I wouldn't recommend it
Show More
to a beginning Software Engineer but I would and do recommend it to intermediate software engineers. People with a couple of years experience that have started to think about the problems addressed in this book. Show Less
LibraryThing member alienhard
The book that said "nine women can't make a baby in a month": projects don't scale with warm bodies. Brilliant.
LibraryThing member JKCollins
I found the essays informative, from a historical and theoretical perspective, but not a lot of help in how to improve management of projects. There are many far better books than this one for actual "how to" tips and tricks.
LibraryThing member librisissimo
I was intrigued to find my computer-systems-major son reading my favorite book from my career days. He verified that nothing much has improved in computer programming since I quit teaching in the Eighties.
LibraryThing member Hectigo
Even after 15 years from the publication of the anniversary edition, this software engineering and project management classic has remained surprisingly relevant. It presents many ideas that have since become very famous, like that adding people to a late project may only serve to make it later.
Show More
Sure, there are some parts that haven't aged as well, but even those have historical value. The book certainly clarified my thinking on large software projects, and provided lots of valuable fodder for thought. Brooks's thoughts on conceptual integrity, the intrinsic complexity of problems and abstraction are insights that every software engineer needs to flourish. If you don't get them from this book, be sure to get them elsewhere. Show Less
LibraryThing member ivanlanin
A great book for thought.
LibraryThing member JavierRiestra
Must read to understand what is software engineering and project management
LibraryThing member Miche11e
I bought the 1982 edition from Abe books because I was too cheap to shell out $33 for the 2005 edition.
It's a good book, but a bit dated. Many of the suggestions are now standard business practices and it is more specific to programming than is really necessary. I bought the book specifically
I laughed when the chapter started talking about the problems with scaling-up pilot chemical plants. I recall that lab VERY well. You build a pilot plant to prove that the process will work. You hope that when you scale it up, the reduced losses will make it efficient. I don't think the analogy is correct, but the lesson is a good one. Don't develop a new process without thorough testing, during which you'll probably have to throw the product away. Work the bugs out during the pilot, and then implement.
It's a good book, but a bit dated. Many of the suggestions are now standard business practices and it is more specific to programming than is really necessary. I bought the book specifically
Show More
because I was interested in using the concept "Plan to Throw One Away" at work.I laughed when the chapter started talking about the problems with scaling-up pilot chemical plants. I recall that lab VERY well. You build a pilot plant to prove that the process will work. You hope that when you scale it up, the reduced losses will make it efficient. I don't think the analogy is correct, but the lesson is a good one. Don't develop a new process without thorough testing, during which you'll probably have to throw the product away. Work the bugs out during the pilot, and then implement.
Show Less
LibraryThing member kiparsky
Brooks is a supremely experienced developer, a solid and subtle thinker, and a very fine writer, both in terms of organization and presentation of ideas and the quality of his sentences. This book is both a must-read and a pleasure to read.
The issues that Brooks addresses may have changed in their
The issues that Brooks addresses may have changed in their
Show More
specifics - I see very little talk about Ada in my other readings on computer science - but not in their essentials. I read several chapters of this book this morning in a coffee shop, then pulled out a stack of printouts to try to understand someone else's code, and much of what I had just read was alive in what I was doing. The importance of clarity and craftsmanship in the design of code: the code I was reading was Java, but written like C, constantly taking advantage of accidents of language to achieve reasonable results in baffling ways. The difficulty of development and maintenance: it took me about ten hours of hard work to begin to understand the organization of this code, before I could begin to address the problems of refactoring, adding features, and documentation which constitute the project I'm assigned to. The "plan one to throw away" concept: the initial code will be refactored, but only in the sense that it will be completely rewritten in place. However, the original writer's ideas provide a lot of the initial mistakes that we would have made ourselves, so his time was not by any means wasted, nor was the time I spent understanding his code. The list goes on - and Brooks understood it all, thirty-five years ago, before object-oriented programming was even a concept. Show Less
LibraryThing member brikis98
A decent & quick read, but many of the essays in the book are obsolete and not applicable to most programmers. However, the core essays that made this book famous are definitely worth a look.
LibraryThing member rlangston
An interesting read of a classic - mostly not relevant to today I would suggest, but some lessons which remain valid.
LibraryThing member teknognome
While a classic, the book is obviously dated. Some of the advice is dated and some of it no longer relevant (concerns about tape drives, documentation on microfiche, etc.), but some of it, including the classic advice about adding people slowing down projects, is still relevant. And I have a
Show More
certain fondness for even the outdated parts, although some of it goes over my head by referencing things I've never heard of (including OS/360, his prime example). Show Less
LibraryThing member scottjpearson
What is relevant about a book, in its second edition, that was originally written a generation or two ago about managing computer projects? The author Brooks led the management of the project for IBM decades ago.
The answer to this question is simple and is evident in the title. Scaling software
Brooks shows the aged wisdom of the idea that computer programming is indeed part communication and not fully mathematical problem solving. Brooks then tries to figure out how to manage projects that are larger and that require more communication. Many of the references are aged and not for those who don't appreciate the history of computation. Nonetheless, for those who like to dabble in history, Brooks' take - always bright - makes us see that the problem of successfully managing software projects is not a new one. Indeed, there are timeless values which undergird technical success.
This anniversary edition includes a retrospective account that evaluates many of the propositions originally put forth decades ago. (Brooks was mostly right, we see.) However, I wish Brooks would also lend some ink - in the light of the additional experience of a couple of decades - to the questions of what makes a software project successful in the first place. Merely being right should fade while understanding timeless values should come to the fore.
The answer to this question is simple and is evident in the title. Scaling software
Show More
projects from smaller-to-larger does not scale linearly. In case you don't know what this means, scaling non-linearly means that a project twice as big does not require twice as many "man-months." It more likely requires four times as many "man-months" because of the need for communication among programmers.Brooks shows the aged wisdom of the idea that computer programming is indeed part communication and not fully mathematical problem solving. Brooks then tries to figure out how to manage projects that are larger and that require more communication. Many of the references are aged and not for those who don't appreciate the history of computation. Nonetheless, for those who like to dabble in history, Brooks' take - always bright - makes us see that the problem of successfully managing software projects is not a new one. Indeed, there are timeless values which undergird technical success.
This anniversary edition includes a retrospective account that evaluates many of the propositions originally put forth decades ago. (Brooks was mostly right, we see.) However, I wish Brooks would also lend some ink - in the light of the additional experience of a couple of decades - to the questions of what makes a software project successful in the first place. Merely being right should fade while understanding timeless values should come to the fore.
Show Less
LibraryThing member ossi
Might have been a useful read 20 years ago, but any pm of more then a couple of years experience and worth a fraction of his salary should be already aware of the major points in this book.
LibraryThing member thorold
Fred Brooks was in charge of a big software development project for IBM in the late sixties. As usual with big projects, the product came in late and over budget, it didn't quite perform as well as had been hoped, and by the time it was on the market there were new technologies coming up that would
The two big quotable ideas in the book are things you've probably seen on a Powerpoint slide if you've ever done project management training.
Firstly, the one that gives the book its title, the idea that real life jobs don't work like those famous maths problems where one worker digs a ditch in ten days and ten workers can therefore dig the same ditch in one day. In real life, the bigger a team gets the more complex the interactions between team members become, and the more time is consumed in internal communication, meetings, paperwork, administration, etc. This seems a very obvious point, but it's one I've often seen overlooked in real life. Senior managers love the idea of big, complicated teams, and it always ends in long delays and mountains of paper...
(It being 1975, Brooks talks about "men" and "man-months" throughout, except in his example of a non-divisible job: "If it takes nine months for one woman to produce a baby...")
Secondly, as a kind of corollary to this, he proposes Brooks's Law: “Adding manpower to a late software project makes it later.” This is a kind of paradox, of course, but the phenomenon it describes is one that probably happens in every workplace. You're overloaded with work, so your boss recruits someone to help you, and the backlog initially gets worse as you have to divert time into training and supervising the newcomer. In a fairly generic job that soon gets compensated as the new person becomes productive, but in a complex project it can rapidly turn a small delay into a catastrophe.
Beyond these headline ideas there is a lot of sound advice about what works and doesn't work in terms of team-structures, meetings, intermediate goals, and effective documentation strategies, all of which is readily portable outside software development (and a lot of which also seems to have survived into today's formal project-management systems). Specific to computing projects, he talks about the importance of focussing design effort on specifying what the product should do, and making sure that that fits within a unified vision, preferably defined by a single architect. The nuts and bolts of how the specification is implemented will take far less time to design than the specification itself.
The 1995 edition comes with a couple of follow-up essays looking at responses to the book, with some thoughts about what he would revise in the light of the unexpected ways computing has evolved. The personal computer revolution, with the consequent shift from expensive custom software to commercial "shrink-wrapped" solutions, has taken him by surprise, as has the rise of object-oriented programming, but neither of these things seems to invalidate the basic principles he set out.
Show More
soon make it obsolete. Rather unusually for a manger, Brooks decided to devote some serious thought to why that had happened, and the result was this little book, in which he lays out some basic principles of project management that have application far beyond the (now largely forgotten) world of big mainframe computing. The two big quotable ideas in the book are things you've probably seen on a Powerpoint slide if you've ever done project management training.
Firstly, the one that gives the book its title, the idea that real life jobs don't work like those famous maths problems where one worker digs a ditch in ten days and ten workers can therefore dig the same ditch in one day. In real life, the bigger a team gets the more complex the interactions between team members become, and the more time is consumed in internal communication, meetings, paperwork, administration, etc. This seems a very obvious point, but it's one I've often seen overlooked in real life. Senior managers love the idea of big, complicated teams, and it always ends in long delays and mountains of paper...
(It being 1975, Brooks talks about "men" and "man-months" throughout, except in his example of a non-divisible job: "If it takes nine months for one woman to produce a baby...")
Secondly, as a kind of corollary to this, he proposes Brooks's Law: “Adding manpower to a late software project makes it later.” This is a kind of paradox, of course, but the phenomenon it describes is one that probably happens in every workplace. You're overloaded with work, so your boss recruits someone to help you, and the backlog initially gets worse as you have to divert time into training and supervising the newcomer. In a fairly generic job that soon gets compensated as the new person becomes productive, but in a complex project it can rapidly turn a small delay into a catastrophe.
Beyond these headline ideas there is a lot of sound advice about what works and doesn't work in terms of team-structures, meetings, intermediate goals, and effective documentation strategies, all of which is readily portable outside software development (and a lot of which also seems to have survived into today's formal project-management systems). Specific to computing projects, he talks about the importance of focussing design effort on specifying what the product should do, and making sure that that fits within a unified vision, preferably defined by a single architect. The nuts and bolts of how the specification is implemented will take far less time to design than the specification itself.
The 1995 edition comes with a couple of follow-up essays looking at responses to the book, with some thoughts about what he would revise in the light of the unexpected ways computing has evolved. The personal computer revolution, with the consequent shift from expensive custom software to commercial "shrink-wrapped" solutions, has taken him by surprise, as has the rise of object-oriented programming, but neither of these things seems to invalidate the basic principles he set out.
Show Less
LibraryThing member acdha
This has held up amazingly well for a book about software engineering written in 1975. Fred Brook's insight into human behaviour is still spot-on even though the technical details can be amusing when you realize that their mainframe had less storage capacity than an RFID tag…
Subjects
Language
Original language
English
Original publication date
1974
Physical description
xiii, 322 p.; 22.7 cm
ISBN
0201835959 / 9780201835953
Local notes
Omslag: C. R. Knight
Omslaget forestiller Mural of La Bra Tar Pits
Indskannet omslag - N650U - 150 dpi
manmonth
Omslaget forestiller Mural of La Bra Tar Pits
Indskannet omslag - N650U - 150 dpi
manmonth
Similar in this library
Pages
xiii; 322
DDC/MDS
| 005.1/068 20 |