In my experience it's more often the other way around.
Most projects I've seen with actually readable code and a consistent overall structure have been written (mostly) by a single coder, of course usually with contributions from others, but not real 'team work'. Of course there are also messy projects by single authors, and readable code bases by teams. But in the latter case: the more the responsibilities are spread, the messier the outcome (IME at least).
I think in the end it comes down to the experience of the people involved.
And then of course there's personal taste, one person's readable code is a complete mess to another.
In any case, the post reads like the author stumbled over one messy project written by a single author and extrapolates from there to all other projects.
In fact, the biggest software atrocities I ever saw were team-based, with people having different opinions and wanting to modify the architecture every six months. And getting away with it because there was no vision.
This is where a good team lead or technical lead, or even Fred Brooks' "Surgical team", or your example of "single developer and contributors": have one person with the vision making the difficult architectural decisions and you'll get some conceptual integrity.
What I see a lot is people with little experience who learned things one way and become unable to understand or respect working code and want to change everything purely for personal preference. Maybe this is where the bias against lone developer code comes from.
This is how I have worked most of my career. It takes checking everyones ego, but turns out great software. Also, the same person doesn't have to be the surgeon on every project. If the project is small enough that 1 person can lead with the vision and everyone else helps, it produces a great outcome.
I think the flaw is that someone believes they turn up to a project and in reviewing code to fit it to a mental model they understand they believe they're improving the readability for others who think like them.
In reality it becomes design by committee, worst of all worlds.
Slightly tangential, but I'm about to leave a project where it gets the review process badly wrong - anyone can and will comment on a review, but only a select few can merge. They have a massive bottleneck of reviews with many held up by conflicting style preferences, or comments on neighbouring code not modified, none of which is able to be resolved by agreement as no one willing to take authority over any one view. Even the simplest one line change can't get merged within a month which essentially means development has stalled other than for the few who have merge rights.
Give me a lone developer's codebase to wrestle with any day.
> They have a massive bottleneck of reviews with many held up by conflicting style preferences
Stuff like this is so frustrating. And it's not only the reviewers fault. I don't consider myself a great coder, but a skill I do have is being able to fit my changes into the codes existing style. Consistency trumps any partial incremental improvement. Unless I have the time and desire to fix the entire code base, new code needs to fit in with the old.
For some reason, I've seen many programmers have a hard time with fitting the style of the existing system. This makes every small change slightly different from others and over time makes the entire system harder and harder to reason about.
I've been places where this has happened, but it's usually a fairly easy fix. Two things that are usually not that controversial: 1) Comments on unmodified code are either deleted/ignored or you create a ticket for the actual issue (and whoever made the comment is reminded this isn't helpful or appropriate in a review). 2) Nitpicky/stylistic things are handed via prettier, precommit hooks, etc. so that everything is consistent and largely doesn't need to be thought about.
And the potentially controversial one: anyone can merge into [almost] any branch, and you merge your own code - so quite often you'll get a PR approval and might wait a day or two to merge it until you decide it's ready. We let anyone merge into any branch but our production branch, however that gets merged automatically and deployed daily unless it's proactively cancelled.
> I'm about to leave a project where it gets the review process badly wrong - anyone can and will comment on a review, but only a select few can merge.
Ugh, I definitely recognize this. There is often a lack of management behind those things. My heuristic is: If I can’t do my job, I tell my manager and ask for help. If they can’t fix it, there’s no point in going on.
There is a large cohort of skilled developers that are desperate for a competent technical leader to come in the room, give them a well-defined work area and let them build widgets exactly to contract specifications. For many, it feels really good to complete these quests. Being placed in front of a blank canvas is overwhelming for most. It takes a lot of patience and experience to start from literally zero with no constraints in sight.
As a technical leader / architect, you don't have enough time to realize your vision throughout. Others have to help. This is exactly what team work looks like.
If some developer is not happy with "helping", then they are welcome to try and carry the entire double-edged sword that is owning 100% of the product architecture. Being king is fantastic when the peasants and customers are happy. It is the worst experience on earth when there is unrest.
Let's be clear - Design by committee works (engineering standards bodies, web standards, et. al.) but this path is usually not competitive in a typical startup environment.
Originality complex, the ability to write original software and document it, is a consideration of personality more so than intelligence. Due to cultural norms and selection bias most people will believe the opposite because education and institutions filter only on intelligence.
I recently learned that conscientiousness correlates negatively with intelligence at about -0.27 which means more than a quarter of the population can organize and architect better than highly intelligent people. This can explain why reliance upon frameworks and third party tools grows proportionally with the size of the team. A single author solving original problems will be less inclined to maintain and juggle concerns beyond the scope and control of their focus area where as larger teams are more inclined to preference administrative concerns, for example configurations and dependency management, over solving for originality.
Education and institutions often filter on certain subsets of intelligence or just good memory.
A lot of exams are a memory test. A lot of courses related to software development are either out of date or don't model the current trends / best practices.
The role of education is to feed the demands of industry... whatever those are. There is still need for COBOL. There is still need for C and C++.
The problem is expectation management. A bachelor's in CS teaching OOP and SQL will not prepare you to write functional code, event logic, transmission control systems, and so forth. Not at all. For some god forsaken reason people believe achievement of education is like checking a box on a job application otherwise already in hand and that said education prepared them for anything.
Most people lack the skills required to perform as most software platforms are designed. Remember, its all about institutionalization and intelligence only. That doesn't work. There simply aren't enough 145IQ people (2-5% of the population) in the world to fill the demand required to self-train across multiple paradigms of application design architectures. The solution provided by industry is to make it more stupid (easy) so that lower IQ people, as low as 115, can participate (about 35-40% of the population). This occurs because both education and industry only filter for intelligence and high intelligence does not correlate with organization, self-discipline, or any other form of conscientiousness.
The reality is that if industry filtered for personality in preference to intelligence they could choose from 25% of the population without dumbed-down (the need for easy) software platforms. That means less tech debt, better documentation, faster time to market, more valuable/flexible products, less burn out, happier employees. It would also mean they wouldn't have to pay under performing junior developers as much as doctors, and it would make expert developers more identifiable as determined by performance compared to peers when there are fewer restrictive constraints (guardrails imposed by industries artificially easier platforms).
In my own experience, dealing with software written with "forced collaboration" (meaning bringing more than 1 developer just for the sake of saying it was done by a team) usually results in more difficulties in later maintenance than the other way around. Specially in micro/tiny services, where sometimes one person can do most of it quickly.
I agree with you take and had the same feeling that the author just seems to have faced one of those cases and extrapolated.
I'm guessing that lone developer projects have a higher variance as they are a direct reflection of the skill of the single developer. Team projects trend to the average.
If you have a very good developer doing a lone project it's probably going to be good. Because they have full control. But I doubt an unskilled developer will have a very good lone project. You want them on a team environment for the structure and mentorship.
Finally, it's worth mixing your developers as their combined effort is worth more in the macro level rather than the micro level.
If you have one developer, he or she will be the expert of that project. If you want a team of multiple developers, and it's infeasible to have any one of them be an expert of the entire system (let alone all of them), then the amount of planning and standardization needed increases quickly. The bigger the team is, the stricter the rules for style need to be, the better the documentation needs to be, etc.
I would expect the cleanest projects to be ones written by single developers because A) these projects will typically be simpler than the ones that require teams, by nature, and B) they will be undistracted / avoid the flaws of design by committee. Think cinema auteur vs. a Marvel or Disney film with an army of writers.
Go lang is a good example of identifying and addressing the problems that appear when your code is managed by a large team.
Fred Brooks had a term for this: Conceptual Integrity. When there's one mind working on the codebase, it's natural that it will have a higher degree of Conceptual Integrity.
A team can achieve this, but they need to have been working together a long time or have a very, very strong technical lead.
For the single developer case, I think maintainability and scalability then comes down to whether the developer follows good practices or not. Commenting, refactoring, reorganizing code, unit testing, etc. But a product or codebase with high Conceptual Integrity is generally easier to expand on because there are common patterns throughout the code, even if it's lacking in comments.
This has also been my experience but I can understand that not all lone developers follow similar conventions.
It can take a while to get used to someone else's conventions, but once you do, the one advantage of a lone developer is that the conventions can be generally consistent. I say "can be" because that has been my experience in many cases, but not all – especially for long lived projects where the conventions evolved as the developer either gained experience or was influenced by other conventions. But, even then, their evolution still has personality to it, that is easy to perceive.
pd: Thinking about it, larger teams with conventions (when they're followed) sometimes achieve a similar consistency to lone developers. So: thank you to all those lone developers that have left their code in a state that has helped me thrive, not fail, :-)
Similarly, my experience is that it requires a single person on the team who cares “too much” about code quality, consistency, etc. They basically forced everyone to comply. This is not intended to be a negative.
Most projects I've seen with actually readable code and a consistent overall structure have been written (mostly) by a single coder, of course usually with contributions from others, but not real 'team work'. Of course there are also messy projects by single authors, and readable code bases by teams. But in the latter case: the more the responsibilities are spread, the messier the outcome (IME at least).
I think in the end it comes down to the experience of the people involved.
And then of course there's personal taste, one person's readable code is a complete mess to another.
In any case, the post reads like the author stumbled over one messy project written by a single author and extrapolates from there to all other projects.