The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

Category: Programming
Author: Frederick Phillips Brooks
4.4
All Stack Overflow 12
This Year Stack Overflow 2
This Month Reddit 4

About This Book

Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his 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, both for readers already familiar with his work and for readers discovering it for the first time. In this twentieth anniversary edition, the original text is accompanied by Fred Brooks' current advice and thoughts based on the newest developments in the computer industry.

The added chapters contain

(1) a crisp condensation of all the propositions asserted in the original book, including Brooks' central argument in The Mythical Man-Month: that large programming projects suffer management problems different from small ones due to the division of labor; that the conceptual integrity of the product is therefore critical; and that it is difficult but possible to achieve this unity;

(2) Brooks' view of these propositions a generation later;

(3) a reprint of his classic 1986 paper "No Silver Bullet"; and

(4) today's thoughts on the 1986 assertion, "There will be no silver bullet within ten years."

Comments

by masterdirk   2019-11-17

https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959

Buy him or her this. It's worth it.

by dpash   2019-11-17

https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/

by jollaffle   2019-07-21

Only for tasks that can be effectively divided among that many people. In software development, adding more people tends to cause the project to take longer, because it requires substantially more coordination and communication.

Check out the Mythical Man-Month to learn more.

by [deleted]   2019-07-21

Cara... interessante esse teu desabafo, porque acredito que isso se passa na cabeça da maioria dos devs.

Trabalho como desenvolvedor há 15 anos já. Como eu vim do Java e sou Backend Engineer, a preocupação (na época que eu comecei a trabalhar) era em certificações (poxa, não tenho a SCWCD etc) e frameworks (Spring, Struts, Hibernate) ou outras API (JasperReports e o escambal).

E ninguém botava fé que na época JS iria ser tão poderoso hoje.

Esse sentimento vem se arrastando por anos mas a real é que as coisas sempre vão mudando, sempre com a preocupação de não estar trabalhando com uma coisa nova como linguagem funcional (Scala, Haskell, Clojure) etc, mas te falar que... no final das contas, qualquer nova tecnologia em TI a gente aprende sem muito esforço (tirando Scala) e nunca vamos saber tudo.

A loucura é que em 2006-2007 eu imaginava que 10 anos depois Java sequer iria existir, tudo ia ser Ruby e on Rails etc mas no final, Java continua firme e forte, sendo o meu ganha pão só que... Os problemas de gestão de projetos continuam a mesma merda, tal como era na década de 70.

A dica que dou é que tu não precisa se preocupar com todas essas sopas de letrinhas. Você não precisa saber COMO usar tudo, mas tendo IDEIA do que é cada coisa (tipo, o que é React, Angular, NodeJS, containers, serverless etc) já é ótimo. Talvez fazer um hello world naquela hora de procrastinação no trabalho já vai ser super lucrativo.

Ah, só um bônus sobre "as dores" dos devs nos últimos 50 anos: https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959

by scarface74   2019-01-03
(None of these are affiliate links)

https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

https://www.amazon.com/Clean-Architecture-Craftsmans-Softwar...

https://www.amazon.com/Patterns-Enterprise-Application-Archi...

https://www.amazon.com/Refactoring-Improving-Existing-Addiso...

https://www.amazon.com/Code-Complete-Practical-Handbook-Cons...

https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...

https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...

And just because it’s asked at every interview.

https://www.amazon.com/Design-Patterns-Object-Oriented-Addis...

I’m focused on AWS these days, but a lot of these principals are universal.

https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-A...

by charlysl   2018-11-20
"On the criteria to be used in decomposing systems into modules" (1972) - because the core principles of modularity haven't changed [https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria...]

"The Mythical Man Month" (1975) - because human nature hasn't changed [https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...]

"The History of Fortran I, II, and III" (1979) - because this historical piece by the author of the first high level language brings home the core principles of language design [https://archive.org/details/history-of-fortran]

"The Unix Programming Environment" (1984) - because the core basics of the command line haven't changed [https://www.amazon.com/Unix-Programming-Environment-Prentice...]

"Reflections on Trusting Trust" (1984) - because the basic concepts of software security haven't changed [https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...]

"The Rise of Worse is Better" (1991) - because many of the tradeoffs to be made when designing systems haven't changed [https://www.jwz.org/doc/worse-is-better.html]

"The Art of Doing Science and Engineering: Learning to learn" (1996) - because the core principles that drive innovation haven't changed [https://www.youtube.com/playlist?list=PL2FF649D0C4407B30] [https://www.amazon.com/Art-Doing-Science-Engineering-Learnin...]

"xv6" (an x86 version of Lion's Commentary, 1996) - because core OS concepts haven't changed [https://pdos.csail.mit.edu/6.828/2011/xv6/xv6-rev6.pdf] [https://pdos.csail.mit.edu/6.828/2014/xv6/book-rev8.pdf]

by jmcomets   2017-09-14
I recommend reading The Mythical Man Month[1] to anyone interested in proper SWE project management. There are so many wannabe managers out there that will just through more people at a project which is slowing down.

To quote the book: "Adding manpower to a late software project, makes it later". There's some really good stuff in there, even for those of us that are less interested in management.

[1]: https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...

by Vaibhav   2017-08-20

The Mythical Man-Month

by Fred Brooks

The Mythical Man Month

by anonymous   2017-08-20

Should I using other patterns?

No, you should not insist on a single pattern.

No design pattern books will ever advise you to use a single pattern. Just like you cannot chop all ingredients in one single way (are you going to dice the spaghetti?), you cannot organise all logic in one single pattern.

Sure, you can make all your Objects use the initialiser pattern, and don't use constructors at all. This is ok. Been there, done that. I like it.

But these objects can be used with Builder or Abstract Factory (if it make things simpler). As long as the builders/factories themselves have initialiser, and that they properly initialise the created objects, then your use of the initialiser pattern will be consistent. Outside of creational patterns, it is usually good to organise objects with structural and behavioural patterns. They do not conflict with initialiser at all.

For example, look at DOM. All nodes are created by the Document object - elements, text nodes, comments, even events. This is the Factory pattern.

Yet the Document object is also a Facade! From it you access the whole system's status, objects, data, you can even write to it! Every DOM operation starts from the Document, it is the Facade of the DOM system.

DOM nodes also implements multiple patterns. They are organised in Composite, let you listen to events with Observer and Command, and handle events in a Chain of Responsibility. They are certainly parsed by an Interpreter, DocumentFragment is a Proxy, svg elements are implemented as Decorators, and createNodeIterator obviously gives you an Iterator.

The point is, good object-oriented design will yield multiple design patterns as a result, intentional or not.


What are the secrets for good code appearance

I think the best looking code is the one that is easiest to understand to you, and the way you read code changes as you gain more experience.

For example my style is too condensed for most programmers, but to me it strikes a good balance. So do develop your own style - you are not me, and you are not yesterday's you either.

Remember this as we go through the styles.

At the lowest level we have coding style - most importantly indent and bracket.

This one is simple, pick the one you like and stick with it. There are language specific styles, and they are often good starting points. Configure your IDE's formatter so that you can format all your code with hotkey.

Above the code syntax we have comment style and naming convention.

Setting rules on comment is fine, sometimes it is necessary for documenting tools. Avoid too much comment in practice. You may also want to decide your namespace and your stand on naming function expressions.

Above these structures, we have logic conventions.

The same code logic can often be done in many ways, some more 'beautiful' than the others in your eyes. Look at this example.

I picked the second style on first sight: no duplicate, logic is sectioned cleanly, format is not my style but reasonable. But many programmers would prefer the first style: logic is plain as day, a few duplications is worth it. While abstract, this level is quite deep - present your logic the wrong way actually increase the chance an experienced programmer read it wrong.

Finally, we arrives at the level of design pattern, about as far as code beauty goes.

The key to keep your code structure beautiful, is using the right patterns at right level to consistently accomplish loose coupling and code reuse, while avoiding pitfalls and over-design.

There are quite some books about beautiful code, and then there are even more books about designing and implementing beautiful software. (Decide for yourself which are beyond your level.) Knowledge is as important as experience, and you can gain them only by spending your time to study, to write, and to revise/refactor your apps.

Feel free to change your mind as you explore and experiment with your code. Changing your mind is a good sign of learning.

But first, familiarise yourself with design patterns. Just don't forget, they are the generic result of applying object-oriented principals to common tasks. It is still up to you to do the design.

Design Patterns Are Not Silver Bullets.

by eob   2017-08-19
You might be interested in this book. It's required reading in many CS curricula:

http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

by lostphilosopher   2017-08-19
If you're interested in this topic, might I recommend:

No Silver Bullet: Essence and Accidents of Software Engineering, Frederick Brooks (1987) - http://www.amazon.com/Mythical-Man-Month-Software-Engineerin...