Following last month’s deep dive into open source history, I’d like to continue with another historical artifact of early computing, Frederick Brooks’ 1975 essay collection, The Mythical Man-Month.
One of my favorite go-to quotes when scoping out development projects or figuring out how to bring a derailed project back on track is Brooks’ Law. It’s perfect, succinct, and never fails to predict the future.
Here, in all its glory, is Brooks’ Law:
“Adding manpower to a late software project makes it later.”Frederick P. Brooks, Jr The Mythical Man-Month
Frederick Brooks was an early engineer at IBM in the fifties and sixties and later started the Computer Science department at UNC Chapel Hill. The Mythical Man-Month was a seminal analysis of software project management, drawing together a number of best practices that feel fresh and relevant even now, almost fifty years later. While there’s plenty of specific language1 and advice that is very out-of-date (the pros and cons of storing your documentation on microfiche?), the conceptual thinking still feels pretty solid. The most well known of these insights, and the centerpiece of the book, is Brooks’ Law.
To paraphrase the law, the more people you have working on a project, the longer it will take to make progress on it.
Building software is not like harvesting crops or painting a fence: you can’t just flood the field with more workers and expect things to move faster. The book explores how development relies on the successful communication of abstract concepts in three separate ways: between humans and other humans, between computer and computer AND between humans and computers. When you boil software development down, it’s all just language – spoken, written, programming, etc. As more humans and/or machines get involved, exponentially more communication is needed, and more complexity ensues.
As the size of the WordPress project continues to grow, it’s worth digging into what Brooks was saying then, to know what lessons the project as a whole can draw going forward. The WordPress project is massive, and many of the major issues we’re facing are essentially failures of communication as the scale of the project, its contributors, their sponsors, third-party developers, and the broader user base grows. There’s just so much of everything.
Code is Like Poetry
Longtime WordPress members are familiar with the phrase “Code is Poetry,” seen across the footer of the WordPress.org websites. Others have tackled this concept in the past, but let me dig into it using concepts from Brooks. He writes that “the programmer builds from pure thought-stuff: concepts and very flexible representations thereof.” In other words, coding, much like poetry, is just the communication of abstract ideas.
“A computer program,” says Brooks, “is a message from a man to a machine.”
Code is poetry not just because it is a message in another language, but because the larger or deeper meaning often hides in the spaces between the actual lines of text. You can’t hold code in your hands or measure its value by the number of characters it contains. You have to infer the deeper meaning of what code will do, what will happen and how it might alter the values it was given. And because others may not infer your original intention, you have to document everything.
Collaboration is Communication
Just as software and poetry have a deeper purpose than what we see in the text, anything that does diverge from the original creator’s intent can cause confusion and communication breakdown. Brooks calls this idea conceptual integrity, that “design must proceed from one mind, or from a very small number of agreeing, resonant minds.” When too many contributors have conflicting ideas about what it is exactly they’re trying to build, a project may fall apart.
Writing code, like cooking, is often more art than science. The saying “too many cooks in the kitchen” applies when it comes to coding, and with an open source project that powers so much of the web, there’s a constant tension between needing a consistent “head chef” with a strong vision, and our ideal democratic principals.
Communication thus becomes the most important part of development. We communicate our goals and intentions to each other. We communicate how we want things to happen. We disagree and need to communicate our way through those disagreements. All of this happens before and during the process of actually communicating these ideas into code, and then discussing the quality and effects of that code.
The WordPress project has recently begun to share some of these discussions on the Make WordPress blog, but it seems clear that many of them start on the GitHub repository for Gutenberg, tucked away in the more than four thousand open issues, or in the millions of lines of conversation in the Making WordPress Slack. Luckily there are a few awesome individuals like Courtney Robertson, Anne McCarthy, Birgit Pauli-Haack, and others who are doing the hard work of bringing more communication to the project.
On the one hand, we simply lose transparency because of the increasing amount of communication happening, like the Trac and GitHub issues referenced above. However, we also lose transparency thanks to the increased fragmentation of communication in the WordPress project. As more and more private walled gardens (e.g. Slack instances) are used to hold the communication vital to this project, we risk more and more conversations flying past each other, inhibiting progress.
Why is open source software unable to use open source software to communicate?
The Tower of Babel
When it comes to large-scale, collaborative projects, Brooks reminds us of the mythic story of the Tower of Babel as “the first engineering fiasco.” For those unfamiliar, the Tower of Babel was an attempt by humans to build something large enough to reach the heavens. God, in his boredom or insecurity, curses the builders with multiple languages, erasing their ability to communicate with each other. The tower eventually falls. Jonathan Haidt recently used the story to great effect as an indictment of social media, while also noticing our growing inability to communicate online successfully.
“The techniques of communication and organization,” Brooks continues, “demand from the manager much thought and as much experienced competence as the software technology itself.” Although WordPress has had the same release lead for the last few years, we’ve heard less and less from that lead about the actual project goals, other than his shared frustration that the Gutenberg project is starting to feel very much behind schedule.
Allie Nimmons’ recent podcast episode, “How Did the Pandemic Affect WordPress Contributors,” highlighted the major Catch-22 in WordPress right now: we need more contributors, but we aren’t successfully communicating with potential contributors to help onboard them. It’s actually very overwhelming to find the right documentation, chat group, codebase, etc., to start contributing. This is something I tried to ask Matt Mullenweg about, but I believe the conversation should go further. As Brooks explains, it typically requires someone already on the project to stop working and spend time communicating to the new contributor. Thus Brooks’ law.
If we’re to avoid reaching an endpoint in our own ability to grow the platform, we all need to urge transparency and clarity in communication. We’re fighting against the growing complexity of our own project, but I believe that if we keep communicating openly and positively, we can continue to see more decades of WordPress growth.
1 Editor’s Note: Brooks’ 1975 book uses “man” as a stand-in for “person” – we’ve maintained his exact language in direct quotes but do not use unnecessarily gendered language, especially when it comes to inclusivity in the tech industry, in our own writing here at MasterWP.