Scaling Software Development
alexgaynor.net
alexgaynor.net
Also, regarding enforcing coverage numbers, in a very large application deteriorating coverage numbers tend to go from x to x - epsilon in every commit which the boundary is not going to catch. So, if one believes the premise of this article it is one of these properties which is automatically going to decrease. These coverage tools are in a way quite similar to automated formatters. They tend to be stupid unless they are configured very well, and what are the chances of that? They tend to provide useful information like that in the test files the coverage is 100% but in the one file that contains a test that is to be run manually it is 0%, which is obviously bad. Since you have such a bad file, you will get a bad rating no matter what else you do.
Rumor has it that if you hire enough monkeys they will type the collected works of Shakespeare at some point. Articles like this makes me think that in fact 'software engineering' is in fact not 'programming intergrated over time' but instead an attempt to validate the hypothesis involving the monkeys in practice. However, for practical purposes, the hypothesis involving the monkeys is actually false and nothing good can come from having lots of developers running around who cannot be trusted with responsibility. Not everybody has to be great but there have to be enough adults around.