Fred Brooks' 1975 book The Mythical Man-Month (40 plus years old by the time you read this book) is the most heavily cited work in all of software engineering literature. Tanenbaum's classic textbook Operating Systems: Design and Implementation makes a (brief) mention of Brooks' title:

Here, there is a direct relevance. To explain why, let's make a variant of the Big-Coffee notation as introduced by Steve Luscher. While perhaps no one outside Luscher's head knows what inspired him to make his point as he did, Luscher is clearly familiar with the classical big-O notation for runtime complexity, and presumably with the fact that it is also used to assess the complexity in other kinds of resource usage, such as memory. But I might suggest that a possible additional inspiration might be helpful as explained by Big Organization complexity. If Big-Coffee complexity can be nightmarish and quadratic at —or as Luscher writes, —something eerily familiar manifests in the communication complexity within a monolithic project.

If there is one programmer on a monolithic project, the complexity is zero, as there is no need to avoid stepping on other programmers' feet. If there are two programmers, the complexity in communication is exactly one connection. If there are three programmers, there are three connections; and if we scale up to 10 programmers, the paperwork scales up to 45 connections. IBM's approach to the OS/360 project was the so-called Big Blue Solution, and it said, "Since there's lots and lots of work we want done, let's hire lots and lots and lots of programmers!" IBM had well over 10 programmers, and therefore had vastly more than 45 connections.

One character that might be appropriate to indicate the complexity of organizational communication is the interconnected HTML dingbat, encodable as ☸ or ☸:

If we are able to retrofit a "Big Organization" complexity of how much communication is needed to prevent programmers from breaking others' work, perhaps no dingbat or emojicon is perfect. But we can speak of monolithic software projects having a quadratic communication complexity—of , or if you prefer, —for developers to keep up with other changes and partially avoid collisions with other developers' work. On the scale of the OS/360 project, this resulted in developers spending over half their day only keeping track of memos, to keep abreast of what other programmers have done.

There is reason to believe that if the OS/360 project had been done with an approach like what Facebook uses for ReactJS plus Flux, there might have been no need to write The Mythical Man-Month.

The combination of ReactJS and Flux is explicitly written so that you don't need to put your hands in every other component's pockets. In fact, it is written so that if everybody is observing the approach, you can't put your hands in other components' pockets unless you find a way to breach the security. The communication complexity is not quadratic (as it was in the OS/360 project) at or ; the number of directions of communication if you have at most one developer per component is vastly smaller, and may possibly be barely above linear at . The difference is enormous in its implications.

While it is not clear that Facebook is being insistently purist enough to achieve the best theoretically possible results, it does seem evident that Facebook—which is one of the largest organizations on the Internet, and may have a frontend development staff comparable to (or greater than) the OS/360 project in size—has communications that scale much better than the monolithic OS/360 endeavor. Perhaps Facebook is one of the many organizations that are quicker to advertise their strengths than their weaknesses. But nothing that I've been able to find in any resource on the Web suggests that the volume of communication between Facebook developers is out of hand, as it was in the OS/360 project, or that the necessary volume of internal communications is onerous enough to be an issue that makes developers' lives genuinely more difficult.