This just in: there are a massive amount of developers working on a single project. Not all of them are on the stability team. Just because they're adding feature X doesn't mean that they're taking any amount of resources away from bugfix Y. It's a false dichotomy typically imagined by those who have never worked on medium to large-sized products.
It would be false if he had said no work on stability was happening. However, new features come with a cost in stability (both through introduced errors and less manpower on the stability teams). Google has been putting a lot of features in (nacl, dart, etc) and it is coming at the expense of the basic browsing experience.
Interesting that as Mozilla figures out it needs to focus on the basics after getting slammed by the smaller, faster Chrome, Google does the exact same thing they did.
It's just Zawinski's law in a cycle. “Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”
"Various studies have shown that software broadly contains something like 6-16 bugs per 1000 lines of code."
As more features are added, the number of bugs will increase, so in a sense everyone who is not on the stability team is on the instability team. Which means the stability team would need more developers as a counterweight...
Here are a couple of details about programming at Google. First, every commit requires a code review. Secondly, in addition to writing your own tests and testing tools, there is a separate set of developers that do nothing but write testing infrastructure, ensuring that it's as easy as possible to test everything as it's written.
Bugs still happen, of course, but they're going to be of the more obscure variety. My chromium 14.0.835.202 has never crashed. Always good to get a backtrace and read the code nearby, and if nothing makes sense, run memtest86.
Not necessarily. It only takes one bureaucrat to reject code that doesn't pass tests or follow required conventions. For example, a good rule of thumb is that no new code will be accepted without documentation.
"It's a false dichotomy typically imagined by those who have never worked on medium to large-sized products"
In my experience it's not necessarily false, especially when the test cycle has a weak regression suite.
One project I worked on was an embedded system with tight resource management requirements. The teams were split into features and stability/performance scrums. Each new feature would have the performance people crying out loud at the new overheads introduced.
A performance/stability-minded code reviewer on each team alongside a strong performance regression test cycle might have seen the project succeed but the pace imposed by a fast agile dev cycle precluded this sort of discipline.
Marketing wanted features and wanted them now - The demo is Friday, chop chop!
Not a false dichotomy but a manufactured one, perhaps.
