How strongly do I recommend The Mythical Man Month?
9 / 10
Although written one thousand years ago, the concepts from The Mythical Man Month still apply to modern software development.
The durability of The Mythical Man Month comes from the author’s reliance on research, not just opinion. Although software engineering has seemingly progressed in practices, we’ve regressed in the formal study of our field.
Where Peopleware focuses on engineering management, The Mythical Man Month comes from a slightly more technical angle making it a more applicable read for Tech Leads.
Your development project is running behind when your boss asks you, “What if we throw more resources at it?” Your boss is having a natural reaction. She knows the Project Management Triangle – if she’s flexible on cost, then time and scope can remain (or even improve!).
Not so fast. Flexing one corner of the Project Management Triangle works well for manufacturing but knowledge work is different because onboarding costs are higher and communication nodes grow exponentially.
Now your once productive engineers are busy onboarding the new people instead of writing code. Sure, you may carve out time for onboarding and try to set a constraint on it but your constraints don’t dictate reality. Onboarding and communicating with these additional engineers will drain whatever productivity you did have.
Likewise, you’ve now greatly increased the complexity of project communications. Four engineers working on a late project requires little coordination. Six engineers is another story, especially when two of those engineers are new.
As an engineering manager, talking about resourcing on a late project will leave you feeling drained. Prepare to look unreasonable.
Whatever you do, don’t go into that conversation referencing Brooks’s Law. Focus instead on the underlying explanation.
Leading tech in a growing startup, I frequently feel our systems pushing back. Finding product-market fit means you frequently build things that aren’t quite right. The idea is close, but something is off and needs tweaking.
When you do nail both idea and execution, you’re likely to hit scalability problems. Those of course fall into the “good problems to have” category.
Brooks recommendation aligns with my experience – when you need a breakthrough, start by looking at the data structures. For most companies, that means looking at your database tables first.
A data-first perspective sends you to the heart of the problem. If you can fix the issue at the data layer, your fix will likely propagate out throughout your stack.
In many cases, the issue is your understanding of the problem at hand. Or at least what your understanding was back during development.
That’s the reality of being in a growing company and discovering iteratively what customers actually want like The Lean Startup suggests.
Brooks writes, “The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 percent) change of introducing another.” The probability of introducing a regression increases as your system grows.
All software engineers have felt this pain. The facepalm moment when you realize that your bug fix introduced a new problem. Two steps forward, one step back.
Brooks points toward two causes. First, the fix you applied is probably local because you localized the bug to its narrowest point of failure. Normally, we call that good problem solving but often it backfires.
Equally common, you didn’t write the original code so you don’t fully understand the consequences of your fix.
Brooks’ solution to this lies in regression testing, which for my team is best done through automation. Find a bug? Write a failing test case, then fix the bug. As your automated testing suite grows, so decreases the likelihood of fixes causing regressions.
Managers and engineers both frequently get this wrong. We think that writing code is the hard part.
Brooks writes, “The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.”
Don’t take the word “specification” too literally here. In modern software development, specs have become less formal and more collaborative. A spec is just a shared understanding of the proposed solution to a problem.
Without a shared conceptual understanding, many companies find themselves in the situation of having too many engineers and too few problem solvers – designers, researchers, and product managers figuring out what we actually needed to build.
Think this stuff is common sense? Wrong.
One company I worked at had 9 engineers, 3 QA people, and the only product direction we had came from our CTO on post-it notes. In two years at that company, I shipped one crappy feature that didn’t solve a problem for anyone.
I believe program design is the crux of the 10x programmer.
Productivity isn’t about lines of code; it’s about programs that are easy to modify. It’s about design.
How would you describe the best structures? Brooks says the best structures are faster, smaller, simpler, and cleaner.
A few years ago, I would have said that the best structures are flexible and support future use cases. There’s a term to watch out for – future use cases.
As Brooks points out, engineers working on their second system are particularly vulnerable to this overengineering trap. For these engineers in particular, I like emphasizing smaller and simpler designs. Solve the problem at hand before worrying about future problems that you may never have.