I don't necessarily buy GP's story, but it's not the same story as "reading up and extending a system is harder than making a system", where group B would have a different starting point as group A.
One developer makes a system in N months, a team of people is hired to rewrite it, it takes 2x or 3x the amount of time. A tale as old as time.
It is kinda obvious from the get go that it would take more time. With 19 developers there is a much larger organisation and communication overhead. If there's more managers, then means A LOT of bikshedding. In enterprise, there's probably someone responsible for the architecture, there will most certainly involve architecture astronautics "to help developers move faster", which will invariably make them slower.
My 'hack demo' was far more 'advanced' with respect to functioning stuff than the winning team, who faked a bit of their presentation. They had a lot of stuff, and a good idea, but... in 2 days, there's not much time to make decisions. Showed a demo after a day to a few others - someone from the eventual winning team kinda smirked and poked a bit of fun, making some comment about how we weren't all that far ahead of his team. I replied back that I was the only developer, and there were only 3 of us, and .. got a small jaw drop from him.
We simply didn't have the overhead of the other teams. We had someone with an idea, discussed in a small team, and me implementing, and I got to say 'no' to a whole lot of things that, in a larger team, we'd have tried to split up and hack on in parallel.
I'm not at all saying the questioning isn't valid - we don't have enough context to know definitively what conclusions to draw. BUT... a small group of people (or individual) with the right tools, aptitude, motivation and time can accomplish a whole lot more than many people assume.
The part about having one dev doing most of the work is even suggested in the book. But of course it's something impossible when "everyone is replaceable" is a requirement for modern businesses.
> I got to say 'no' to a whole lot of things that, in a larger team
That's one of the #1 tricks of writing good software for fast and cheap. Engineers get to say no to stupid shit from product/design/management/C-level.
That individuals can truly develop amazing things which most teams could only hope to reach shouldn't be doubted. Plenty of solo projects with absolutely astounding results exist to prove the opposite. Enough that one could argue they fall outside the realm of 'they are geniuses with a rare talent'. Management types like to pretend developers are idiot savants capable of programming, but good developers are far more than that.
Bring in a junior developer in the middle and you're gonna have to train them, slowing down the process. Bring in a new senior and he might not slow you down, but won't be productive for a while. Bring a designer and that overhead becomes even higher. Bring a second designer and it's even worse. Another stakeholder? Same deal.
Dailies and Retros are too crowded? Divide the team in two and bring another manager? Same deal.
Software is hard. Head count doesn't mean speed. In fact it often means the opposite.
EDIT: About solo devs, it's funny that in HN there is a bit of a cult for good developers that manage to make things useable for others, and that includes everything from products to libraries and languages. But as soon as someone tells a story about someone or some team being unable to take over a solo-dev work, their work is immediately treated as if it were complete garbage. One thing that made me a better developer was stopping having this attitude. Maybe the reason I can't understand is that I am the one who's not good enough.
EDIT 2: Btw, sorry if my tone sounds as if I'm disagreeing with you. I’m not! I also don't think you were doubting the OP. It's just that I keep seeing this industry making the same bad assumptions about team-size, year in year out.
'More' meaning in every non-technical context. More paper, more communication, more heads to count, etc.
I worked in a Softbank startup that start hiring like crazy for positions that weren't necessary, because that's what Softbank asked for. It was a crazy place to work where anything bringing productivity gains and solving developer pain wasn't rewarded. But, of course, we several people working on developer experience, because there was not enough work for all developers.
On the other hand, maybe this is a good thing. It means more jobs for developers. More money redistribution. But on the other hand it is soul crushing to see something that could be a 2-hour walk on the park becoming a 3-month transatlantic expedition involving several teams.
In the job above, I worked for a few weeks on a team that was responsible for one single screen, and this screen had three checkboxes which we used to update some third-party API. No, there wasn't much more than that. It made me want to kill myself.
However, I really wanted to point out I only gave a single example of something I’ve seen multiple times, I’ve witnessed the same effect (first-in advantage) even with rewrites, and (perhaps surprisingly) even with the same people the second time ‘round! There are lots of potential reasons, but the 2nd time round with the same people is a curious and interesting one, because it says something about our tendency to want to rewrite things and our inability to estimate the time to re-solve the same problems even having solved them before. I’ve seen this a few times, twice (two completely separate instances at separate companies) it was whole-team efforts that ended up costing millions of dollars in delay and the org regretted doing a rewrite instead of an incremental effort.
People often pretend you can. In big companies a new team will “take ownership” of an existing system. But they won’t really understand it until they rewrite it. Wanting to rewrite is not a character flaw, it’s just an inherent part of the process.
That said, if one person wrote the first version, then one person can write the second version. Teams don’t have to get bigger.
The reason that first-in people are more productive is they are witness to all of the initial assumptions and initial architecture, they decide and understand how every corner of the thing works, and they understand how to refactor it quickly and change core pieces of the pipeline. By the time other people join later, there’s a whole bunch of dependencies that make it both difficult to understand the whole system and time-consuming to change - a core piece has subsystems that depend on it, and each subsystem has unit tests, etc. etc.. People who don’t have familiarity with the entirety of the system have to make small changes and tread carefully, and this is almost completely independent of the skill of the programmer.
The strongest example of this is when I built a codebase with a partner for a cloud service in a year, and then sold the company to a group of engineers that I believe are probably better than I am. It took them much longer, several years, to get to the point where they could swap out and rewrite major features. But it’s absolutely clear to me this wasn’t because I’m more productive than they are, it’s because the system complexity was high, learning what I did and why took a lot of time, my documentation was sub-par, I wasn’t around enough and able to help them understand what I did.
BTW did you try to get other programmers involved? Is it possible part of the issue was doing too much solo work and not communicating enough? Not saying this has anything to do with you, but I’ve known and managed some very highly skilled programmers that are difficult to work with despite their apparent code productivity. It just means that skill and code output are only part of the job, and high skill can’t always overcome other issues.