3 ms·

Making two teams compete like that is a horrible idea. Both teams know that no matter how hard they work, their work may be thrown away. I've heard horror stori

by eska 6y ago

Making two teams compete like that is a horrible idea. Both teams know that no matter how hard they work, their work may be thrown away. I've heard horror stories like this in a post mortem about the development of Sonic 3D for Saturn back then for example. There were two teams tasked with making a sequel, and only the better one would be released. Management's idea was that it was supposed to be a flagship title and had to be good. Both teams worked themselves to exhaustion and almost everyone quit the company, the rest got fired due to failure.

bluGill 6y ago
Even if the above doesn't happen, it is hard to say what you learn from two teams. Maybe one team is worse. Maybe one team got lucky because the serious bug was 1 in a million and not found, while the other spent weeks tracking down a similar level of complexity bug that happened every time and so had to be fixed... I can come up with more. The only thing fair is to give one team 6 months (ideally with a couple contractors who are experts to teach them best practices) to try the new thing. Less than 6 months and they are not far enough along the learning curve to make any useful statements. If you want a work done comparison you need to give half your teams (minimum 20 teams, ask a statistician for more details if you want to go lower or could go higher) that 6 months, and then after that give them a year to use the new one in real work, and compare that final year.
- nickelcitymario 6y ago
  Totally fair @eska and @bluGill. I really wasn't thinking in terms of "This is the right way to manage a project." I was simply trying to identify some way to do a better and more accurate comparison between Rust and C++. You're perfectly right that it would be awful to be pitched against each other in this way. So I recant my suggestion, but maintain my critique about using lines of code in a single project as somehow validating a language choice. There are too many variables. And, more to the point, the refactored code will almost always be much better, regardless of the language selected.
dan_quixote 6y ago
Deathmatch programming doesn't sound very pleasant. But I hope most people here don't feel a morale hit when their code gets tossed. Inherently, I understand the desire for one's creative work to live on, but that's essentially incompatible with this industry. And I also have found much joy in turning-down/deleting existing services I've written. My team celebrates these events and it's always fun to give that high-maintenance service a viking funeral.

by eska 6y ago

bluGill 6y ago

Even if the above doesn't happen, it is hard to say what you learn from two teams. Maybe one team is worse. Maybe one team got lucky because the serious bug was 1 in a million and not found, while the other spent weeks tracking down a similar level of complexity bug that happened every time and so had to be fixed... I can come up with more. The only thing fair is to give one team 6 months (ideally with a couple contractors who are experts to teach them best practices) to try the new thing. Less than 6 months and they are not far enough along the learning curve to make any useful statements. If you want a work done comparison you need to give half your teams (minimum 20 teams, ask a statistician for more details if you want to go lower or could go higher) that 6 months, and then after that give them a year to use the new one in real work, and compare that final year.

nickelcitymario 6y ago
Totally fair @eska and @bluGill. I really wasn't thinking in terms of "This is the right way to manage a project." I was simply trying to identify some way to do a better and more accurate comparison between Rust and C++. You're perfectly right that it would be awful to be pitched against each other in this way. So I recant my suggestion, but maintain my critique about using lines of code in a single project as somehow validating a language choice. There are too many variables. And, more to the point, the refactored code will almost always be much better, regardless of the language selected.

dan_quixote 6y ago

Deathmatch programming doesn't sound very pleasant. But I hope most people here don't feel a morale hit when their code gets tossed. Inherently, I understand the desire for one's creative work to live on, but that's essentially incompatible with this industry. And I also have found much joy in turning-down/deleting existing services I've written. My team celebrates these events and it's always fun to give that high-maintenance service a viking funeral.