Who the Heck is Fred Brooks??

Welcome to AKF partners continuing series on notable personalities that impact business and technology.

Today, we ask who the heck is Fred Brooks??

Meet, Doctor Frederick P. Brooks Junior, a titan of computer science and software engineering. Born in 1931 he made indelible marks on the discipline of software development and on how we think about large software projects and the challenges they present his insights changed the world of software development. He's perhaps best known for his seminal book, The Mythical Man Month essays on software engineering, first published in 1975 in it, Brooks distilled observations and lessons from his experiences managing the development of the IBM System 360, a foundational mainframe computer. Brooks' insights have proven crucial for anyone grappling with scaling technology, architecture and organizations.

Have you heard of Brooks's Law? It states that adding manpower to a late software project makes it later. This principle highlights the complexity and challenges of communication within growing teams. The idea is that as more people are added to a project, the overhead of communication and coordination grows exponentially often offsetting the benefits of additional manpower, unlike other fields in software, adding hands isn't always the solution to better grasp Brooks's law.

Let's explore a hypothetical scenario.

Imagine a company Tech Corp and their software product initiative project alpha. It was planned for a duration of 10 months with five developers, but in six months, they have finished just 30% of the work in a panic. Tech Corp adds five more developers. But now the original team has a new challenge, training newcomers, new developers need time to orient themselves to the work ahead. They must understand the system, the coding style and the team's vision before they can contribute in a meaningful way. Communication paths explode from 10 possible channels to 45 individual communication channels.

More talk less code.

This explosion of communication paths can drastically slow things down. Instead of coding, developers might find themselves in meetings, answering questions or clarifying doubts more and more often as the new developers start contributing, integrating their work with the existing system can lead to system conflicts, new code, clashes with the old, leading to bugs and delays. This results in further delays as the team spends time debugging and ensuring everything integrates smoothly. The original team struggles with the sudden changes, overwhelmed or frustrated by the influx of new members, morale drops. This can further slow progress as team dynamics shift and members adjust to the new working environment.

Six more months and still project alpha isn't done. More developers didn't mean faster completion while more hands did contribute to more code. The overhead introduced by the sudden growth meant that the acceleration everyone had hoped for did not materialize the project took longer than if the company had either stuck with the original team or had planned for a larger team from the start.

Kkey takeaways:

Adding more people to a late software project may result in even more delays due to the multifaceted complexities of communication, training and integration.

This is the power of Brooks's law. More is not always better. Growth requires understanding and appreciation of human collaboration in technology. Fred Brooks taught us that.

We encourage you to dive deeper into Brooks' insights at AKF partners. We share insights like these with our clients at every engagement.

If you are having trouble with delivering a large software project, invite us in. We would love to help. Oh! And grab a copy of the Mythical Man Month today.