More resources should make the number of fixes possible per year greater, but it may not substantially reduce the time from notice to fix any single issue (and may, because of organizational overhead involved, sometimes increase the time for particular fixes over an organization with fewer total resources.)
Maintaining code is not a trivially parallelizable function.
> Maintaining code is not a trivially parallelizable function.
Yes, I know this, thank you.
But we are talking about billions of dollars vs. millions of dollars (for Linux / BSD). We are talking multiple orders of magnitude(!) more money. I realize there isn't a Silver Bullet, but the fact that what we have heard coming out of Microsoft about they're management practices year after year is ABYSMAL, it is not an excuse. Especially when people who are working for free, with no/little organizational support, can beat them at releasing security fixes.
> because of organizational overhead involved
So maybe they should fix it? How is their incompetence at running an organization a valid excuse? If it was a problem they cared about they would be researching how developers and teams of developers perform best, how best to organize code, etc. Instead they used stacked teams for years on end. I have no sympathy.
If it's as serious problem maybe they should stop making new operating system features and devote more resources to fixing, cleaning up, depreciating, etc. the ones they already have?
They are making business decisions, and their ineptitude at security is a result of them. There are no excuses of "they are the only one's doing X" for "they are bad at doing Y when they do X" when they are promising Y!
How is it a fallacy? Because management is incompetent? If your budget goes from 1M to 10M even a child could show you how to spend 1M and throw the rest into a big fire or something. Maybe run two agile teams at 1M each.
Yea, but that doesn't mean you still don't get some additional speed out of hiring more developers, especially when correctly organized, with sane management policies, and good software development practices.
The point is that Microsoft has the money to hire 100x more developers than the other guys, they should at least be well organized enough to deploy a part of that man power effectively.
Lets put it this way, there are 7 companies out there (at least) maintaining various different distributions of UNIX that can patch quickly, why can't Microsoft patch their 7 operating systems as quickly? From my view what you are saying is that because Microsoft is a monolithic company with 7 code bases it is somehow harder than 7 companies with 1 code base each? How does that track? Especially when Microsoft has a 100x more money than each of those other companies.
I'm not saying there is such a thing as a man-month. I'm saying there are ways to organize production, teams, and software so that people can provide more work than in poorly managed environments.
My point wasn't that more money itself induces potential slowness, but added infrastructure & scope that surround it (not necessarily even in the same department) often can.
Ignoring more money is pretty unlikely to be an option as a whole, and inefficiencies generally cascade down to some extent.
Other departments matter in some ways, but bugfixing can be self-contained and mostly avoid slowdowns.
But even more important is that these outside slowdown effects are pretty minor. If this was software development then you might have no recourse and you'd be somewhat slower overall. But this is handling many many independent projects. You can hire more teams without having man-month problems, and then handle bugs efficiently.
>Ignoring more money is pretty unlikely to be an option as a whole, and inefficiencies generally cascade down to some extent.
Again, I blame management. A nice sturdy cardboard box as a manager is impervious to social effects from other departments, and it can soak up extra cash too.
I expect anyone being paid to manage to do a better job than a box. Not to go along with the flow uncritically.
