Adding manpower to a late software project makes it later.
-Fredrick Brooks, The Mythical Man-Month
I was on a trip into San Francisco with a friend, and he suggested to me a book which is considered a classic of software engineering – The Mythical Man Month, by Fredrick Brooks. It’s a bit of an older book, being published a good twenty years before I was even born, but held in high esteem by every peer I’ve mentioned it to. So, I hunkered down and read through it. Some sections (such as discussions about and tape-drives) certainly show their age, but for the most part, it was still relevant.
Rather than privately reflecting about the book and moving on, I figure it’ll be better to write a blog post. Maybe nobody will read it, but I see no point to keeping my thoughts to myself.
There are countless synopses of the text on the web, such as this one. I will instead cover what I think has changed, between the book’s time and the modern (2016, for you future folks).
The Tar Pit
I feel that for the most part, this chapter is timeless. My only real remark is that with modern development tools, the transitions could be greatly eased. This is entirely opinion-based, but I feel that with a small group adhering to some rigid syntax decisions and documentation standards, costs could be cut from a factor of x3 to x2.
It’s worth considering this text was created in the age of assembly. In the modern age, many tools ease the workflow of programmers, and make it easier to properly develop a program that can then transition into being a full-fledged Programming System Product without as much hassle.
The Mythical Man-Month
The premise of this chapter will always hold true – men and months are not exchangeable.
I feel that exposure to the Internet definitely has exacerbated the issue Brooks raises – we overestimate our productivity due to optimism. With resources on how to achieve small tasks only a query away, it’s easy for a programmer to fancy themselves more experienced than they truly are. An overestimation of knowledge can be very dangerous for scheduling.
The Surgical Team
The surgical team’s needs have changed since the original Man-Month.
I’d say a toolsmith is no longer needed, as it’s now incredibly difficult to hand-roll a tool and have it out-perform an existing utility.
Language specialists are still helpful, but certainly don’t merit a dedicated roll anymore. I’d advocate a smaller team, and argue that each member should be skilled enough that a conversation during a break could resolve a language issue.
The editor is also dead weight, for smaller projects. Doxygen and automatic code generation is a blessing. I’d further contend that the co-pilot should absorb the editor’s role – with modern tools writing documentation is much easier than in 1975.
I’d say that for a modest project, a four man team of a surgeon, copilot, administrator, and tester could produce great results. This is obviously untested – I’m going to go recruit some freshmen to test this.
Aristocracy, Democracy, and System Design
With modern languages, I think it’s incredibly easier to dive into programming without an architectural specification. This, as Brooks suggests, leads to a implementation nightmare. In fact, I’d imagine it’s the cause of many startups failing.
Make architectural specifications people.
The Second-System Effect
I think it’s more common now to fall into this effect, with the ease of refactoring being greater than during the age of assembly. From personal experience, it’s incredibly easy to procrastinate on real progress to refine existing work. This is a danger to avoid.
Passing The Word
Another one that’s easily ignored in the startup world – have a core set of documents. Be concrete in decisions, and arbitrate trivial manners brutally. Don’t waste time on small decisions.
Why did the Tower of Babel Fail?
Be mindful of how your hierarchy promotes communication, and don’t put people in situations where they can’t excel.
Calling the Shot
This hasn’t changed too much. Assume a work week has about 1/2 to hours it does, you’ll wind up slipping in places.
Ten Pounds in a Five Pound Sack
This section is dated in content, since we no longer have the consideration of program space as a cost. However, it’s still good to consider relevant constraints of your system and to know where trade-offs are occurring.
Upon further thought, this is still true when it comes to leveraging accelerators, and when provisioning time. While there aren’t many physical resource constraints anymore, programs still take time to run, and accelerator time becomes a scare resource.
The Documentary Hypothesis
This chapter made me realize how much I take for granted the Internet, when documents are readily fetchable. This chapter is otherwise pretty timeless. I wish all the organizations I belong to stuck to publishing the documents enumerated here online.
Plan to Throw One Away
This chapter will never change, it’s correct to assume that change is entirely inevitable. So, I’ll instead highlight that it’s still wise to design a throw-away system before the first real system. Much better than having to throw away your first system.
This chapter is a bit out of date, for the average developer. Modern machines have converged to a few ISA’s (x86, x86_64, ARM, etc.), and are powerful enough for us to have our vehicle and target machines be the same devices. With the exception of programs managing data centers, embedded devices, or other smaller edge-cases, a program can usually be developed and tested on a local PC these days.
The Whole and the Parts
Top-down design is a fairly common idea – most programmers I’ve met develop their code in broad strokes first, as described. I feel that the advent of object oriented programming enforces this behavior by pushing inheritance as a feature.
Hatching a Catastrophe
This section is timeless, and aged well. I’d like to point out that it suggests having an oversight group for projects, which I think is a fantastic idea. I’m dealing with fuzzy milestones now, and I see the merit in having an oversight group forcing employees into good work habits.
Also problem vs status meetings with managers is a distinction I wish I saw more frequently. Being an open and restrained manager is the right way to go.
The Other Face
This chapter speaks on documentation. I can’t see it’s take on documentation being dated, but I feel that with high level language, there are fewer levels of detail to document on. It’s no longer necessary to document at a fine granularity, where context and proper syntax and naming conventions make the purpose of a line of code immediately understood.