[I]f we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
It's appropriate on so many levels. Lines of code can be part of a measure of what has been accomplished, just like a heavy airplane is a great accomplishment so long as it flies. Yet we would never consider adding weight to be our goal.
It might be for aircraft construction but not aircraft design. Since programmers aren't typists entering already-complete programs, programming is more asking to the latter, not the former. You want aircraft to be lighter and programs to be shorter, and measuring progress by movement in the opposite direction is foolish.
But weight relative to a final value is not a reasonable metric for completeness. It's discontinuous with irregular, changes, so it has no utility in predicting how long until completion, for instance.
> “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
Nice. And then we have Windows that needs dozens of gigabytes disk space and
can do nothing useful at all, while debootstrapped Debian chroot can easily
serve a dynamic website backed by a database and weigh two orders of magnitude
less (minus the data, obviously).
The analogy is quite apt, but the context of the author's company makes the
sentence hilarious.
The fact that people do something stupid and attribute it to a scientific discipline which suggests they shouldn't do it does not discredit that discipline.
Similarly, the Ariane 5 disaster doesn't mean that the idea of measuring the physical world with science is wrong.
There's nothing wrong with Taylorism. It works very well in a variety of fields (e.g. Uber and Amazon use Taylorism very effectively to manage their line workers). The fields where Taylorism isn't used (e.g. software development) are far less reliable and effective - Amazon can guarantee that your package will arrive in 2 days, can you guarantee that your software team will ship on time?
I wouldn't say that Taylorism is why those workers succeeded.
I'd say that those workers were successful in spite of Taylorism. Don't fall into the trap in thinking that just because a methodology was applied, that it contributed to success.
The best evidence I can give in support of this is Deming:
Lots of early physics was also not done very well, lots of fudges, etc. Does that discredit the idea of applying science to particle movements? Does Freud discredit the entire idea of psychiatry?
Physicists kept doing science, and it got better. Actual proper science has developed to the point where the computer I'm typing this on has a complex network of billions of logic gates which operates correctly billions of times a second. I can reasonably expect the CPU to continue to work for decades.
When managerial "scientists" can achieve anything even remotely comparable to that level of reliability and reproducibility, it will be time to take it seriously as a science. Until then, it just isn't one.
Many fields don't give that same level of reliability and reproducability; climate science, psychology and environmental engineering are all in the same boat. Guess none of them are sciences.
The fundamental idea of Taylorism isn't bad, it's just hugely overapplied and oversimplified. Using pure Taylorism in the 21st century is like using pure Freudianism. There have been plenty of more recent innovations. We could at least start with W Edwards Deming.
A difference is that Freud didn't put any particular stock in the scientific method. He said that his theories were proven by his "cures" (many of which have turned out to be bogus).
[I]f we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.