"""Here’s an important thing to know. Whenever you read one of those books about programming methodologies written by a full time software development guru/consultant, you can rest assured that they are talking about internal, corporate software development. Not shrinkwrapped software, not embedded software, and certainly not games.
...
Last week Kent Beck made a claim that you don’t really need bug tracking databases when you’re doing Extreme Programming, because the combination of pair programming (with persistent code review) and test driven development (guaranteeing 100% code coverage of the automated tests) means you hardly ever have bugs. [But this doesn't apply to our shrinkwrapped product. Our shrinkwrapped product has to be robust to a variety of environments and use-cases whereas software for corporate environments doesn't.]
....
Kent is right, for other types of development. For most corporate development applications, none of these things would be considered a bug."""
EDIT: I don't often see context like this brought up in discussions. But at the same time, I think principles like "shorter iteration cycles are a good thing" can loosely be applied in different cases, even if not quite in the same way for different 'worlds'.
Comments
The key part to me:
"""Here’s an important thing to know. Whenever you read one of those books about programming methodologies written by a full time software development guru/consultant, you can rest assured that they are talking about internal, corporate software development. Not shrinkwrapped software, not embedded software, and certainly not games. ...
Last week Kent Beck made a claim that you don’t really need bug tracking databases when you’re doing Extreme Programming, because the combination of pair programming (with persistent code review) and test driven development (guaranteeing 100% code coverage of the automated tests) means you hardly ever have bugs. [But this doesn't apply to our shrinkwrapped product. Our shrinkwrapped product has to be robust to a variety of environments and use-cases whereas software for corporate environments doesn't.] ....
Kent is right, for other types of development. For most corporate development applications, none of these things would be considered a bug."""
EDIT: I don't often see context like this brought up in discussions. But at the same time, I think principles like "shorter iteration cycles are a good thing" can loosely be applied in different cases, even if not quite in the same way for different 'worlds'.