
Scaling Software Development - anotherevan
https://alexgaynor.net/2020/feb/18/scaling-software-development/
======
cjfd
There is quite a bit of the good having to suffer for the bad going on here.
Which, frankly, is just immoral. It actually is not very important that coding
styles vary somewhat between one part of an application versus another but it
does preclude good developers from formatting things nicer than what the
automatic formatter would do. And the automatic formatters are actually not
that great.

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.

