One is social structure. 260 people is a large group, and there has been research suggesting that social structure is a more effective predictor of software defects than “technical” metrics.
With this size group coordination issues are going to loom large, so the way meetings are planned, organized and run will play a critical role in the group’s “distributed cognition”. The description of the relationship between “coders” and “verifiers” is tantalizing but almost certainly oversimplified.
Another is design. You don’t get near zero defects on half-million-line codebases without some strong design principles: modularity, avoidance of data coupling, and so on. Popular press won’t mention that because people’s eyes will glaze over, but I’m pretty sure that this code isn’t sprinkled all over with global variables. The article says “one-third of the process of writing software happens before anyone writes a line of code”—but then goes on to reveal practically nothing about this early part of the process, other than the cliché that it produces a lot of documentation.
The article makes a dangerous claim that its four broad conclusions generalize widely: it claims to “illustrate what almost any team-based operation can do to boost its performance to achieve near-perfect results”. The problem is that taking this kind of advice too literally leads directly to “cargo cult” software engineering.
You can easily make developers write thousand-page design specifications but that in no way guarantees defect-free code—in many cases reliance on written documentation is in fact a direct contributor to poor quality, insofar as a more interactive form of communication offers more opportunities for detecting and correcting errors.
One is social structure. 260 people is a large group, and there has been research suggesting that social structure is a more effective predictor of software defects than “technical” metrics.
With this size group coordination issues are going to loom large, so the way meetings are planned, organized and run will play a critical role in the group’s “distributed cognition”. The description of the relationship between “coders” and “verifiers” is tantalizing but almost certainly oversimplified.
Another is design. You don’t get near zero defects on half-million-line codebases without some strong design principles: modularity, avoidance of data coupling, and so on. Popular press won’t mention that because people’s eyes will glaze over, but I’m pretty sure that this code isn’t sprinkled all over with global variables. The article says “one-third of the process of writing software happens before anyone writes a line of code”—but then goes on to reveal practically nothing about this early part of the process, other than the cliché that it produces a lot of documentation.
The article makes a dangerous claim that its four broad conclusions generalize widely: it claims to “illustrate what almost any team-based operation can do to boost its performance to achieve near-perfect results”. The problem is that taking this kind of advice too literally leads directly to “cargo cult” software engineering.
You can easily make developers write thousand-page design specifications but that in no way guarantees defect-free code—in many cases reliance on written documentation is in fact a direct contributor to poor quality, insofar as a more interactive form of communication offers more opportunities for detecting and correcting errors.