[gregjor]

I can tell you my experience. I see a lot of foreign code, since I work almost exclusively on legacy code (not necessarily old, just not supported by the original developers). Some I would call low quality, most not that bad. I have to spend time and effort understanding the code, even the code I would call high quality.

I get my customers after their original developers have gone, and after multiple other programmers have deemed the code unreadable and unmaintainable. My value proposition comes down to putting in the effort to understand and work with code that every programmer who looked at it before me wanted to rewrite. In ten years doing this kind of work I've only told one customer to start over from scratch.

Fred Brooks talks about "conceptual integrity" and the detrimental effect of too many designers and programmers in The Mythical Man-Month. If you read about the development of Unix and C at Bell Labs you come away with the same impression: a small group of like-minded programmers who achieved conceptual integrity. When only one programmer writes code that integrity usually shows. The more programmers involved the harder maintaining conceptual integrity becomes.

[ken]

It's useful to hear about your background, and based on your article, it's not too surprising. I'm beginning to believe that there's no such thing as a "typical" programmer (no offense!). I know people who write software for aerospace, political dissidents, major web services, healthcare, weekend hackathons, embedded systems, etc., and all of these have completely different kinds of requirements.

Brooks' book is on my shelf (it's one of the N=1 cases!), but I've come to the realization that I'm the only one who actually believes what he says. More than one manager has had it sitting on their desk when they told my team "This project is at risk of running late, so we're adding some additional people..." Never have I ever worked for a manager who agreed to implement anything in it.

Conceptual integrity is an attribute we really have no metrics for (AFAIK), which means it will naturally suffer as a project grows. That's probably why so many managers have no problem sacrificing it for short-term speed. It's a tragedy of the commons. You get credit for adding features, and for creating a new project to replace an old one, but you never see the downside from the gradual removal of conceptual integrity which caused the creation of the replacement project in the first place.

It's also a dramatic difference from literature. When George R. R. Martin is late with the next "Game of Thrones" volume, nobody suggests adding more authors to hit an arbitrary deadline. We'd rather let the schedule slip by a few years than sacrifice any conceptual integrity.

[gregjor]

My experience with Brooks’ Law matches yours: More honored in the breach than in the observance. I also have worked for managers who display TMMM in their office but add people to projects to meet a deadline.

I think decisions like adding more people and sacrificing conceptual integrity and quality reflect a human bias to favor short-term results and to discount or ignore possible future costs.