I can't see why you don't buy it. I have seen this kinda thing happening dozens of times in my career. Both in startups (especially in startups!) but also very frequently even in enterprise.

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.

Years ago I did a weekend hackathon. My team came in second. The first team was 13 people - 8 or 9 were 'devs' of some stripe. Our team was 3 people - me as the only developer.

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.

Yep. One of the most important books in our field, The Mythical Man Month, agrees with a lot of this. But we still choose to keep ignoring it at our own peril.

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.

Well, you're describing a scenario where you didn't really need a big team. So it stands to reason that if you have a bunch of people who want to participate--while you theoretically have more knowledge and insights to draw from it's not surprising in the slightest that can be overwhelmed by communication/discussion overhead in a tightly time-bounded situation.

It wasn't surprising to me, but it was somewhat surprising to others in the event. It just sort of goes against the conventional wisdom of "more=better", but yes, in hard-deadline situations, having one person push through is often a better option than trying to coordinate between groups.

Not fully buying it doesn't have to do with not believing the feasibility of GP's story. Rather, stories tend to be more complex than any given individual tends to represent them, and I'd like to give a full team of 19 developers the benefit of the doubt they didn't run around like headless chickens. Case in point, if you mention managers and communication outside those 19 developers, that already changes things quite a bit.

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.

I'm completely ok with giving a team of 19 developers the benefit of the doubt, but in this case it doesn't matter if they're good or bad developers. They're 19 people. There's gonna be lots more overhead if it's a project that one person was able to do themselves.

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.

Your assumption is fair given the industry has been trending towards 'more' as a way to be 'better', without understanding how things scale, how development isn't the same as a manufactory line and multiple types trying to pawn their arrogance off as others simply not "understanding it". I'm sure you can relate with many anecdotes where mentioned bad assumptions were sold as ICs being faulty rather than those in charge.

'More' meaning in every non-technical context. More paper, more communication, more heads to count, etc.

Exactly. The trend to more is often forced by investors etc, but this thinking is also seeping into developers.

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.

Because if you rewrite, there’s less obligation to previous choices and tests. This should facilitate dev speed, as long as second-system is avoided.

You’re right, my starting point is slightly different, if we take the top comment at face value, or at least I agree with you that I did make slightly different apparent assumptions. Though since we’re deconstructing it now, there’s no reason you should assume the 19 person crew wasn’t looking at the poster’s original solution, the post didn’t specify same inputs, and it’s quite unlikely to be the case IMO. Poster may be ignoring the quality and extensibility of the newer design, or may be ignoring performance in favor of functionality, or ignoring documentation or updated requirements. Or, maybe they really are faster and more productive than 19 people, of course I don’t actually know anything. :)

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.