3 ms·

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

by ratww 4y ago

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.

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

by ratww 4y ago

BlargMcLarg 4y ago

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.

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

mixmastamyk 4y ago

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.

mgkimsal 4y ago

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