4 ms·

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

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.

ratww 4y ago
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.
ghaff 4y ago
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.
- mgkimsal 4y ago
  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.

ratww 4y ago

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.

ghaff 4y ago

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.

mgkimsal 4y ago
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.