The Mythical Man  Month

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.

Engineering leaders should strive to reduce maintenance costs by increasing quality. However there is usually a minimum of around 40% of effort that will be spent on maintenance.

Knowing that 40% of your team’s time will be spent on maintenance, Engineering Managers and Tech Leads should account for maintenance time during planning and estimation. Build refactoring and bug fixing into your team’s regular workflow, weaved in with new feature development.

When the first delivery date is missed, your team feels guilty. After the second or third missed delivery, morale is in the pits. Now you’re on a death march.

The remedy to repeatedly missed deadlines and resetting morale includes a combination of steps:

• Acknowledge the missed delivery as quickly as possible. Always tighten feedback loops.
• Break down the work, including estimations
• Ensure all of your team’s work is visible
• Collaboratively set SMART goals, with an emphasis on Measurable and Achievable. Beware vague definitions of done. The best definition of done is in production. Also look out for false alignment, often indicated by mindless head nods that suggest people aren’t really bought around the goal. Always aim for goal alignment throughout your software engineering team.

Remove unused features as quickly as you add them. Regularly prune your product of clutter to avoid a bad user experience. Doing so will also reduce the cognitive load of your engineering team, which is tasked with maintaining all features regardless of usage.

As a developer builds their first system, they come up with idea after idea to implement next time. The first system remains small, perhaps a bit hacky, but functional.

When it comes time to build the second system, the engineer has a backlog of ideas to pull from. They focus on reusability and modularity over meeting customer needs. Pragmatism is thrown out the window in favor of perfection. Target dates are missed and ultimately the engineering team is left with a codebase so abstract that it does not fit the problem at hand.

Realistically, building an overly complex system and regretting it later is a right of passage for software engineers. Engineering Managers should know this and be on the lookout for developers falling prey to these premature optimization traps.