By Andrew Park | 2024-08-09
Over the past 18+ years as a Vice President of Engineering, I've consistently managed to defy Brooks's Law in numerous situations when adding developers to late projects. Brooks's Law famously states that "adding manpower to a late software project makes it later" due to increased complexity and communication overhead.
Here’s how I’ve successfully navigated this challenge:
The first key factor is cultivating a culture where every software developer is dedicated to creating highly maintainable and readable code. This effort is reinforced by detailed architectural-level documentation and advanced diagramming techniques that enable developers to quickly zero in on the 0.1% of the code they need to focus on within a multi-million LOC codebase. This allows them to concentrate on the necessary feature additions or bug fixes much, much faster than possible without these benefits.
The second key factor is shaping a system I refer to as Tech Adoption Radars, which empowers our most senior technical staff with strategic control over the technologies we use. This system distributes the responsibility of tracking emerging technologies across the software landscape—from front-end to back-end, machine learning to large language models (LLMs), and cloud technologies. By making proactive decisions on technology adoption, we ensure significant overlap in technical skill sets across our development teams, making it easier to seamlessly integrate new developers into existing projects.
These two factors together typically overcome the increased complexity and communication overhead that often hinder adding developers to late projects, effectively enabling what I call "Staffing Agility."
The irony is that by following Fred Brooks's advice to cultivate a team of great software craftsmen and maintain a highly readable codebase with strong architectural documentation, you can defy Brooks's Law in many situations, proving that it isn’t an unbreakable “Law” after all.
It's important to note that Fred Brooks never referred to his observation as a "Law"—it was a key insight from his experience at IBM. The term "Brooks's Law" was later popularized by the software engineering community to encapsulate the principle.
As a closing thought, I want to emphasize that Fred Brooks has been my greatest influence in software engineering philosophy. Throughout his two books, “The Mythical Man-Month” and “The Design of Design,” he asserts that great software products come from nurturing great talent within the company. Brooks's insights inspired me in 2004 to develop methods for cultivating software craftsmanship talent, which have been effectively implemented in our organization since 2006.
If you're a Vice President of Engineering or CTO interested in understanding how to implement the two key factors above to achieve Staffing Agility and defy Brooks's Law in your organization, feel free to reach out to me via LinkedIn.
Comments