Book Summary 43— The Mythical Man-Month

Michael Batko
MBReads
Published in
2 min readFeb 25, 2018

--

I often forget how a book ends up on my reading list — this is one such book.

I think I must have put it there as I wanted to learn more about how developers work and think.

The Mythical Man-Month is a very outdated book, which does provide some, interestingly still applicable, insights into the programming world. It is a written by Frederick Brooks — the father of the IBM system. It summarises the programming challenges of the time — the first edition from 1975, the second (the one I read) 20 years later from 1995.

Why is writing an initial program from scratch so much faster than fixing a large one?

  • no cross-program testing required
  • less cross-system debugging
  • less communication issues
  • less people working on it (which creates managerial complexities — A LOT OF THEM — mostly training and communication)

Why is programming fun?

  • sheer joy of making things
  • pleasure of making things that are useful to others
  • fascination of complex puzzle-like objects and watching them work
  • joy of always learning
  • delight of working with a tractable medium

The Woes of programming?

  • One must perform perfectly
  • Other people set ones objectives
  • Dependency on others (ie other programmers)
  • Grand concepts are fun, nitty gritty bugs just work
  • Last bugs are way harder to find than first ones
  • Before you finish there’s usually already a better solution on the way

Why does programming always take longer than assumed?

  • We always assume that all will go well
  • Effort does not equal Progress — they are not interchangeable
  • Estimates are uncertain, so we don’t even try to stick to them
  • Scheduled time is poorly monitored
  • When schedules go over time, we add more manpower (which takes even more time)

Key Takeaway

More developers on same project does not solve the problem. Training and communication exacerbate the issue and makes it harder to work for everyone.

The key is to split the work in bit sized modules between teams, who trust and can rely on each other through well organised communication channels.

--

--