This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

This chapter was added to the 20-year anniversary edition of 1995 and is a transcript of a paper Brooks wrote back in 1986 titled “No Silver Bullet – Essence and Accident in Software Engineering“, which won him the Turing award, often described as the “highest distinction in computer science” and “Nobel Prize of Computing”.

In it, Brooks addresses the essential tasks of building software and suggests:

• Exploiting the mass market to avoid constructing what can be bought;
• Using rapid prototyping as part of a planned iteration in establishing software requirements;
• Growing software organically, adding more and more function to systems as they are run, used, and tested;
• Identifying and developing the great conceptual designers of the rising generation.
  Continue reading “16. No silver bullet” →

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

Documentation is needed.

Others need to understand what our application is, what it does how it does it, how it behaves. The application code, as well, needs to be understood, not only by the machine but also by the next developer reading it.

We need to document all the way from a faraway view of the system to a detailed view of the system.

Then the question is: What and how to document?
Continue reading “15. The other face” →

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

Plenty of projects, if not the vast majority, end up getting delayed… Some more than twice the initial estimated time and cost. This happened up until 1986, when the book was published, but it still happens today. I feel it is, sadly, very common.

But how does this happen?

How can we prevent it?
Continue reading “14. Hatching a catastrophe” →

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

Curiously enough, Brooks starts this chapter by mentioning something I say every once in a while:

The challenge is not simply to build something that “works”. It is to build something that really works in the way the end user needs it to work, with conceptual consistency, minimal technical bugs, and that can be maintained and extended throughout a long life.
Continue reading “13. The whole and the parts” →

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

The work quality and efficiency of a crafter depends a lot on the tools at hand.

In this chapter, Brooks makes a case for this statement validity for software developers as well and gives a list of essential tools needed for software development.
Continue reading “12. Sharp tools” →

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

Experience tells Frederick P. Brooks that the first system built is always barely usable. So many years after the book was published, that is also my experience: I never worked in a company that didn’t have at least one previous version of their software that was completely thrown away! Continue reading “11. Plan to Throw One Away” →

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

Why should we have formal documents? Continue reading “10. The Documentary Hypothesis” →

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

In this chapter, Frederick P. Brooks, tells us about performance requirements. Of course, the context was different, so the examples and terminology need some translation to today’s context… Continue reading “9. Ten Pounds in a Five-Pound Sack” →

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

This chapter deals with estimations, which still are somewhat of a problem nowadays… Continue reading “8. Calling the shot” →

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

This seventh chapter is about how a software development department should communicate and how it should be organised. Continue reading “7. Why did the Tower of Babel fail” →