4 ms·

If they had allocated 1k devs into n teams to develop different approaches and review and test each other's code and approach. No, the result would've been a be

If they had allocated 1k devs into n teams to develop different approaches and review and test each other's code and approach. No, the result would've been a better patch and probably not that piece of hot garbage.

thatfrenchguy 9y ago
There's probably no 1000 good VM engineers out there, in the world.
- dmix 9y ago
  Yet it didn't take 1000 of them to fix it on other OSes. Why are we even debating 1000 devs anyway? That is hardly the point and throwing more and more bodies at a programming problem is hardly ever a solution, nor one I proposed in my original comment. It's ultimately a matter of talent, resources, and proper management. Which is hardly an insurmountable problem for a major tech company which decades of experience solving world-is-ending bugs.
  - chris_wot 9y ago
    I put it down to lack of openness to a wider review than just Microsoft engineers.
amluto 9y ago
All but a very small number of those teams would have spent quite a while reading manuals, reading code, and learning how the kernel entry code and pagetable handling code worked. Then they'd come up with something, but there would be a severe shortage of reviewers. Not to mention that the whole problem would most likely leak once that many people knew about it.
rhizome 9y ago
I suggest reading The Mythical Man Month sometime, you're not accounting for the complexity of running such an "n-teams" scheme.
- stagbeetle 9y ago
  Anything sufficiently complex can be broken down into simpler pieces. This includes most developer generalists.
  - TeMPOraL 9y ago
    Anything sufficiently complex can be broken down into simpler pieces plus the glue holding those pieces together. In human organizations, that glue itself gets incredibly complex and expensive, as number of pieces grow.
    - stagbeetle 9y ago
      I disagree that glue is expensive and complex. When you build a ply-wood tower in school to see who's holds up the most to compression, you don't douse your entire structure in glue. You get points off, because it adds so much to weight! People are the plywood, fragile, finicky, and useless if left to their own devices. Management is the middle school kid who needs to take the wood he's been given and make something that will hold up to all the weight that'll be put on top it. In order to do this, he's been given a hot glue gun and enough glue to mummify the entire thing if he so chooses. Most of the kids will rush bullheadedly (or should I say uncaringly) into gluing the sticks together into something that "looks like it should work." They use too much glue, the structure isn't optimized for load handling, and when the day of truth comes, it crumbles down when the bucket that's supposed to hold the weight, destroys it! What is glue? Whatever management wants it to be. It can be a team leader or a hastily configured IRC channel. In my experience (this includes organizing, delegating, and making sure that 40 devs-et-al get what's needed done), if you choose your sticks right, taking the time to make sure they're not hiding any structural faults, you can make the job 65% easier. If you lament that choosing sticks if difficult, I reply with "it's just practice." The main issue I've seen, has been the all too common "there are no good managers." Especially in technology. The remedies for this? There's no bandaid. Each manager has to realize his personal shortcomings and fix them. But, to throw up his hands and say "the more people working on a project, the slower it'll get done," is a nice way to say "I can't handle all these people, but I'll excuse that away by saying it's inevitable. It's even industry 'common sense!'"

thatfrenchguy 9y ago

There's probably no 1000 good VM engineers out there, in the world.

dmix 9y ago
Yet it didn't take 1000 of them to fix it on other OSes. Why are we even debating 1000 devs anyway? That is hardly the point and throwing more and more bodies at a programming problem is hardly ever a solution, nor one I proposed in my original comment. It's ultimately a matter of talent, resources, and proper management. Which is hardly an insurmountable problem for a major tech company which decades of experience solving world-is-ending bugs.
- chris_wot 9y ago
  I put it down to lack of openness to a wider review than just Microsoft engineers.

amluto 9y ago

All but a very small number of those teams would have spent quite a while reading manuals, reading code, and learning how the kernel entry code and pagetable handling code worked. Then they'd come up with something, but there would be a severe shortage of reviewers. Not to mention that the whole problem would most likely leak once that many people knew about it.

rhizome 9y ago

I suggest reading The Mythical Man Month sometime, you're not accounting for the complexity of running such an "n-teams" scheme.

stagbeetle 9y ago
Anything sufficiently complex can be broken down into simpler pieces. This includes most developer generalists.
- TeMPOraL 9y ago
  Anything sufficiently complex can be broken down into simpler pieces plus the glue holding those pieces together. In human organizations, that glue itself gets incredibly complex and expensive, as number of pieces grow.
  - stagbeetle 9y ago
    I disagree that glue is expensive and complex. When you build a ply-wood tower in school to see who's holds up the most to compression, you don't douse your entire structure in glue. You get points off, because it adds so much to weight! People are the plywood, fragile, finicky, and useless if left to their own devices. Management is the middle school kid who needs to take the wood he's been given and make something that will hold up to all the weight that'll be put on top it. In order to do this, he's been given a hot glue gun and enough glue to mummify the entire thing if he so chooses. Most of the kids will rush bullheadedly (or should I say uncaringly) into gluing the sticks together into something that "looks like it should work." They use too much glue, the structure isn't optimized for load handling, and when the day of truth comes, it crumbles down when the bucket that's supposed to hold the weight, destroys it! What is glue? Whatever management wants it to be. It can be a team leader or a hastily configured IRC channel. In my experience (this includes organizing, delegating, and making sure that 40 devs-et-al get what's needed done), if you choose your sticks right, taking the time to make sure they're not hiding any structural faults, you can make the job 65% easier. If you lament that choosing sticks if difficult, I reply with "it's just practice." The main issue I've seen, has been the all too common "there are no good managers." Especially in technology. The remedies for this? There's no bandaid. Each manager has to realize his personal shortcomings and fix them. But, to throw up his hands and say "the more people working on a project, the slower it'll get done," is a nice way to say "I can't handle all these people, but I'll excuse that away by saying it's inevitable. It's even industry 'common sense!'"