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 mythical man-month” is a historical, emblematic and seminal book about management of software development projects. It was first published in December 1st 1974, but republished 20 years later, in 1995, with four extra chapters. Despite having been written so long ago, it is still today a reference and a worthwhile reading, with the due context adjustments.
The author, Frederick P. Brooks has been involved in the development of some of the most important and emblematic early electronic computers and has been awarded countless times throughout his career, including the Turing Award, generally recognized as the highest distinction in computer science and the “Nobel Prize of computing”.
This is the first chapter, and Frederick P. Brooks starts off by identifying the craft of system programming and the joys and woes inherent in it.
The first step is to identify the types of product, and how it can evolve:
A programming system
A programming product
The program system product
It starts off on the top left corner, with the simplest form of a program, an experiment, a lean startup kind of project, and ends up in the bottom right corner, a full-fledged enterprise application.
Why do we code?
- The joy of creating things;
- The joy of creating things that are useful to others;
- The fascination of complex, puzzle-like things;
- The joy of always learning;
- The delight of such flexible media used, only a small step away from imagination.
It’s funny to see how I can perfectly relate to the motivations of the developers from over 40 years ago!!
Why is it difficult?
- It must perform perfectly (or it won’t compile);
- The developer depends on others to provide the objectives, resources and information;
- The developer depends on others code, often poorly designed, poorly implemented and incomplete;
- Finding and fixing bugs in implementation and design is painful;
- A product may become obsolete even before delivery.
Again, I can perfectly see how these reasons are still so current nowadays.