1. The tar pit

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 program

Commonly produced in garages;
Complete, ready to be run by the author in the system on which it was developed.

A programming system

A component in a programming system;
Collection of interacting programs;
Input and output conform, in syntax and semantics, to explicit interfaces;
Conforms to explicit requirements;
Tested with other system components;
The more components in the system, the more costly it is to build one component.

A programming product

Generalization;
Can be run, tested, repaired and extended by anybody;
Usable in many systems;
Usable with many sets of data.

The program system product

Costs 9 times as more as the simple “A program”
This is the intended product of most system programming efforts.

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.