REVIEW: The Mythical Man Month: Essays on Software Engineering

As a classic software engineering text, this book is only helped by the addition of Brooks’ latest essays and reflections on his original conclusions. Remember, it won’t do you any good unless you read it.

“As a classic software engineering text, this book is only helped by the addition of Brooks’ latest essays and reflections on his original conclusions. Remember, it won’t do you any good unless you read it.” Rating 10/10

Jason Bennet
The Mythical Man Month: Essays on Software Engineering by Frederick P. Brooks, Jr. (Addison Wesley, ISBN 0-201-83595-9)

While this book has some years on it, the fact that it is still around is a testament to the strength of the text. This latest addition contains additional essays and thoughts about engineering. So, read below and enter into the wonderful world of software engineering.


Before I launch into my review of The Mythical Man-Month, I would be negligent if I did not explain the meaning of the first edition of this book. It’s in 1975. Programmers slave over some of the earliest dumb terminals on massive mainframes from the Great Monopolistic Satan of computing, IBM. Maybe, if their lucky, the programmers can work on a minicomputer from that upstart company, DEC, and their PDP series of computers. FORTRAN and COBOL are your staples, with some PL/I thrown in for good measure. C is a blip on the horizon, just starting to make its way out of Bell Labs. Assembly language is still widely used throughout the industry. Enter Frederick Brooks, one of the industry’s originals. Brooks is reflecting on his time at IBM, specifically his working on the System/360 and its operating system, OS/360 (unique names, no?) during the mid-1960s. Brooks is trying to figure out what was done right, and what was not, especially in how the overall program was structured and managed. He thus sets out to write one of the first treatises on software project management, an indispensable part of software engineering. Twenty-five years later, we are still reading the book and learning from it. In an industry where most books are useless after six months, this book is almost prehistoric. Remember, though, what level a book must reach to last so long.

What’s good?

You might be wondering why this book has lasted so long. The answer is simple: the technology of the book is secondary to people’s lessons. Simply put, Brooks’ points are the following:

  1. Programming must turn into software engineering in order to continue to improve the state of the art.
  2. Any well-engineered product must be conceptually and architecturally whole.
  3. The tar pit of software development can only be escaped through a conscientious, dedicated process.

There are so many classic lines in this book that a simple review cannot account for them all. The most famous, of course, is Brooks’ Law of adding people to a late project (hint: it doesn’t help). Surgical development teams, the second-system effect, and the importance of documentation are all covered, sometimes for the first time, in MMM. Through the course of the book, Brooks covers all facets of what must happen to successfully complete a major software project, and in all parts, he gives a firm foundation for solid software engineering and project management. In fact, this was the first major book to accurately assemble the knowledge needed to engineer a large software project into one place and relate it from the perspective of a finished project.

In addition to the original chapters, Brooks’ essay from 1986, No Silver Bullet, is included, along with Brooks’ thoughts on his book twenty-five years later. These essays alone are worth reading, as they give an accurate estimate of where the industry is now. Suffice to say, the easy part is behind us. It’s real work from here on in.

What’s bad?

What’s bad about this book is that people don’t read it. There’s no particularly good reason, they just are too busy reading the latest book on today’s fad. The irony, of course, is that today’s fad will be laughed at next year, while MMM will still be around a decade from now. If you were assigned this book in school, read it again (you probably didn’t the first time :-). If you’ve never heard of it, read it tomorrow.

What’s In It For Us?

Why should any of us read this book? What does project management matter to a bunch of semi-organized groups? Aren’t we doing fine as it is in our striving for World Domination? Well, yes and no.

On one hand, we don’t have the pressures of commercial software. If Apache comes out tomorrow instead of today, no matter. Everyone else is just as bad, so we just have to not be worse. For that matter, most open-source projects are blessed with one or a few leaders who keep everything on track and in one vision. We don’t have too many projects with lots of different architects.

On the other hand, we’ve been blessed with low expectations. No one expected us to succeed, so any measure of success was a victory for the movement. Now, all eyes are on us. If a release comes out a month late, everyone will think we’re no better at keeping a schedule than Microsoft. If we have to rewrite another application because we did a poor design job, we aren’t offering a valid alternative. We have to be better than everyone else to prove ourselves, and we cannot do that in an individually-oriented environment. If the open-source community can learn the lessons of MMM better than the rest of the industry then we win.

More to the point, we as an industry must raise the expectations of our software. We need to strive for accurate schedules. We need to avoid the second-system effect. We need to understand why you cannot just add people to a late project to speed it up. In short, we need to care about producing quality software on time, instead of just getting stuff out there.

Table of Contents

  • Preface to the 20th Anniversary Edition
  • Preface to the First Edition
    1. The Tar Pit
    2. The Mythical Man-Month
    3. The Surgical Team
    4. Aristocracy, Democracy, and System Design
    5. The Second-System Effect
    6. Passing the Word
    7. Why Did the Tower of Babel Fail?
    8. Calling the Shot
    9. Ten Pounds in a Five-Pound Sack
    10. The Documentary Hypothesis
    11. Plan to Throw One Away
    12. Sharp Tools
    13. The Whole and the Parts
    14. Hatching a Cataastrophe
    15. The Other Face
    16. No Silver Bullet – Essence and Accident
    17. “No Silver Bullet” Refired
    18. Propositions of The Mythical Man-Month: True of False?
    19. The Mythical Man-Month after 20 Years
  • Epilogue
  • Notes and References
  • Index


Text written by Jason Bennet and extracted from here

Purchase the book over here at Amazon

Angular Material Design vs Polymer vs SB Admin Bootstrap

Neste post vou documentar minha pesquisa para a escolha da melhor biblioteca de web component, para um projeto web mobile, utilizando AngularJS.

Angular Material

O projeto Angular Material é uma implementação do Material Design em AngularJS. Esse projeto provê um conjunto de reutilizáveis, bem testados e acessíveis componentes UI, baseados no sistema Material Design. Similar à coleção Paper elements do projeto Polymer, Angular Material é suportado internamente pelo Google, pelo AngularJS, Material Design UX e outros times de produtos.

Esta opção é a que mais me agrada, visto que trabalha muito bem com o AngularJS, que já é certeza no projeto.


A biblioteca Polymer foi feita para tornar mais rápido e fácil, para os desenvolvedores, criar maravilhosos e reutilizáveis componentes para os navegadores modernos.

Em geral, ele foca no uso de componentes web. Cria elementos customizados e evolui tanto quanto a web evolui. Até o momento, só suporta as últimas versões dos navegadores modernos. Segue uma imagem que explica a arquitetura do Polymer.

Esta opção é um vislumbre das novas possibilidades que o HTML5 e os novos componentes web podem nos oferecer.


Ionic é um ótimo open source front-end SDK para desenvolvimento de apps híbrido mobile com tecnologias web como: HTML5, CSS e Javascript. Ionic é focado no “look and feel” e interações UI para um app. Atualmente utiliza AngularJS.

Porém, o Ionic está descartado do meu estudo, visto que o foco do meu projeto é web e ele, apesar de ter uma boa atuação web, é focado no mobile, por isso não garante perfeita execução nos navegadores web. Isto é dito na própria documentação do Ionic.

É provável que, em um futuro não tão distante, seja criada uma branch do projeto utilizando Ionic para uma versão totalmente mobile. Mas isso também depende do lançamento oficial do Angular 2.0 e outras decisões arquiteturais.

SB Admin 2

É um tema administrativo, painel de controle (dashboard), ou aplicação web UI, baseado em Bootstrap, juntamente com o poderoso plugin jQuery e funcionalidades herdadas.

Esta opção é a que menos considero, porque o Bootstrap está desgastado, mesmo que com uma grande comunidade e número de plugins e aplicações. Levando em consideração que o AngularJS é certeza no projeto e que ele sempre precisou de muitas adaptações/plugins/modules/gambiarras para que o bootstrap rodasse bem com ele, seria trabalhoso utilizá-lo. Se não existisse o Angular Material esta opção seria a minha favorita.

Então, qual a diferença entre Polymer e Angular Material?

Angular Material já está adaptado para trabalhar com AngularJS, utilizando diretivas e services. O Polymer é uma biblioteca para criação de componentes web personalizados. Angular Material utiliza a biblioteca Paper elements do Polymer, então, eles não são inimigos, são tecnologias amigas que caminham juntas, porém com um foco diferente.

Diretivas Angular vs Custom Elements

Polymer (mais especificamente Shadow DOM) provê a habilidade para compor JS, CSS e HTML encapsulado em componentes personalizados, assim como as diretivas AngularJS.

As diretivas Angular são conceitualmente similares aos Custom Elements, mas elas são implementadas sem o uso da API para componentes web. Diretivas Angular é uma maneira para construir elementos personalizados, e Polymer e a especificação de componentes web são os padrões-base de como fazer isso.

Similar ao AngularJS, Polymer Elements provê um template e bi-direcional data binding. Entretanto, eles também provêm funcionalidades como o Shadow DOM, que permite encapsulamento do CSS. Diretivas Angular não tem nenhuma noção de encapsulamento de estilo, mas é esperado que isto seja incorporado por uma eventual nova funcionalidade.

No futuro, ambos poderão ser usados conjuntamente. Porque custom elements serão o DOM, eles irão trabalhar sem problemas com frameworks como AngularJS. O time do AngularJS disse que eles irão eventualmente usar a API de Web components (custom elements, Shadow DOM, etc).


Utilizarei o Angular Material, pois, além de ter grandes qualidades do Polymer, ele tem o AngularJS por trás tornando-o mais forte e vivo por mais tempo. Nada é eterno, principalmente neste mundo da tecnologia, mas sabemos que um poderoso framework, mantido por uma poderosa organização (Google), sempre leva vantagem. E como o Angular Material já nasceu feito para o AngularJS, ele se destaca em relação ao Polymer. Contudo, acredito que em breve o Polymer seguirá o mesmo caminho e será uma ótima opção, juntamente com o Angular 2.0.

Angular 2.0 é outro assunto que precisa ser estudado, mas ainda é cedo para este projeto. De qualquer forma, deixarei links aqui no final para leitura complementar, casos se interessem.

“May the Force be with you”

Leitura complementar

Angular 2.0


REST e SOAP: Usar um dos dois ou ambos?

Desenvolvedores web têm uma grande quantidade de tecnologias que podem escolher, de ferramentas para acesso simples a bancos de dados, integração com serviços em middleware, a softwares do lado do cliente. A quantidade de opções em si já é um desafio, e escolher uma abordagem específica para construir partes de um aplicativo web exacerba o problema.

Neste breve artigo, vamos nos concentrar em uma dessas escolhas: SOAP ou REST. Ambas possuem vantagens e desvantagens e fica na mão do desenvolvedor determinar a melhor abordagem para cada caso em particular.

A maioria dos desenvolvedores tem exposto seus serviços utilizando REST, que faz uso de um padrão de URI (Uniform Resource Identifier), fazendo uma chamada para um serviço web como em:âmetros=xx

O REST é simples de entender e pode ser adotado em praticamente qualquer cliente ou servidor com suporte a HTTP/HTTPS. Os desenvolvedores que o utilizam citam, como principais vantagens a facilidade no desenvolvimento, o aproveitamento da infraestrutura web existente e um esforço de aprendizado pequeno.

Por outro lado, o SOAP, avô das interfaces de serviços web, não deixará de ser usado tão cedo. Com o SOAP v 1.2, muitas das deficiências percebidas nessa tecnologia foram corrigidas e aumentou a facilidade de uso. Além disso, a sigla SOAP deixou de representar “Simple Object Access Protocol”. Na especificação 1.2 da W3C, SOAP é apenas o nome da especificação.

Utilizar o SOAP 1.2 traz uma carga adicional não encontrada ao usar REST, mas há também vantagens. Primeiramente o SOAP é baseado em XML, de três formas: o envelope, que define o conteúdo da mensagem e informa como processá-la; um conjunto de regras de codificação para os tipos de dados; e o layout para os procedimentos de chamadas e respostas. Esse “envelope” é enviado por meio de (por exemplo) HTTP/HTTPS. E uma RPC (Remote Procedure Call) é executada, e o envelope retorna com as informações do documento XML formatado.

Uma das vantagens do SOAP é o uso de um método de transporte “genérico”. Enquanto que o REST faz uso de HTTP/HTTPS, o SOAP pode usar qualquer meio de transporte existente para enviar sua requisição, desde SMTP até mesmo JMS (Java Messaging Service). No entanto, uma desvantagem percebida no uso de XML é a sua natureza prolixa e o tempo necessário para analisar o resultado apresentado.

A boa notícia para os desenvolvedores web é que ambas as tecnologias são muito viáveis no mercado atual. Ambos REST e o SOAP conseguem resolver um grande número de problemas e desafios na web, e em muitos casos tanto um como o outro podem ser utilizados para fazer o que querem os desenvolvedores.

Mas uma história não contada é que ambas as tecnologias podem ser misturadas e combinadas. O REST é fácil de entender e extremamente acessível porém faltam padrões, e a tecnologia é considerada apenas uma abordagem arquitetural. Em comparação, o SOAP é um padrão da indústria, com protocolos bem definidos e um conjunto de regras bem estabelecidas.

Pode-se afirmar, então, que casos onde o REST funciona bem são:

  • Situações em que há limitação de recursos e de largura de banda: A estrutura de retorno é em qualquer formato definido pelo desenvolvedor e qualquer navegador pode ser usado. Isso porque a abordagem REST usa o padrão de chamadas GET, PUT, POST e DELETE. O REST também pode usar objetos XMLHttpRequest (a base do velho AJAX) que a maioria dos navegadores modernos suporta.
  • Operações totalmente sem-estado: se uma operação precisa ser continuada, o REST não será a melhor opção. No entanto, se forem necessárias operações de CRUD stateless (Criar, Ler, Atualizar e Excluir), o REST seria a melhor alternativa.
  • Situações que exigem cache: se a informação pode ser armazenada em cache, devido à natureza da operação stateless do REST, esse seria um cenário adequado para a tecnologia.

Essas três situações abrangem muitas soluções. Então por que ainda precisamos considerar o uso do SOAP? Mais uma vez, o SOAP é bastante maduro e bem definido e vem com uma especificação completa. Já a abordagem REST é apenas isso: uma abordagem. Está totalmente aberta. Por isso ao se encontrar uma das situações abaixo, o SOAP pode ser uma ótima solução:

  • Processamento e chamada assíncronos: se o aplicativo precisa de um nível garantido de confiabilidade e segurança para a troca de mensagens, então o SOAP 1.2 oferece padrões adicionais para esse tipo de operação como por exemplo o WSRM (WS-Reliable Messaging).
  • Contratos formais: se ambos os lados (fornecedor e consumidor) têm que concordar com o formato de intercâmbio de dados, então o SOAP 1.2 fornece especificações rígidas para esse tipo de interação.
  • Operações stateful: para o caso de o aplicativo precisar de informação contextual e gerenciamento de estado com coordenação e segurança, o SOAP 1.2 possui umaespecificação adicional em sua estrutura que apoia essa necessidade (segurança, transações, coordenação etc.). Comparativamente, usar o REST exigiria que os desenvolvedores construíssem uma solução personalizada.

Como se vê, cada uma das abordagens tem sua utilidade. Ambas têm problemas nos quesitos de segurança, camadas de transporte etc.; mas ambas podem realizar o trabalho necessário e trazem sua contribuição para o desenvolvimento de aplicações web.

Portanto, a melhor abordagem é a flexibilidade, pois não importa qual seja o problema, no mundo de hoje do desenvolvimento web, conta-se com excelentes resultados ao fazer uso de um desses padrões.