Nicely put, overall. Your points on the demands of “management” echo this other Dijkstra screed.
However I have to disagree with your claims of “high grade reasoning” in this particular instance. You say “some of the work affects the later work in very clear ways”: what ways?
The ways most people in the profession know are less than clear, otherwise we wouldn’t see all the arguing back and forth about which language, which OS, which framework best serves the interests of “later work”; or about which technique is best suited to prevent defects, or any of a number of debates that have been ongoing for over four decades.
I’ve been doing this work for over twenty years now, and I still find the determinants of software quality elusive on the scale of whole programs. Sure, for small or “toy” examples you can always show the advantages of this or that technique: unit testing, UML models, static typing, immutability, lazy evaluation, propagation, whatever. (I’ve perhaps forgotten more of these tricks than some “hotshot” young programmers have ever learned.) But at larger scales of programming efforts these advantages start being swamped by the effects of other forces, that mostly have to do with the social nature of large scale software development.
The most direct and clear way:
I made a decision how to divide up functionality between methods in a class. The following code that uses this class will all be directly affected by this decision. If this decision is made poorly, there will be growing extra cost from the difficulty of use of the class, as well as the cost of refactoring will be growing over time. Cause and effect.
(We do not need to have an agreement which technique, framework, language, etc is the best and which is the worst to agree that this choice will affect the following code and that amending this decision later on will cost more and more. It is straightforward that choice of the language affects the following code, even if it is not straightforward if its bad or good)
Of course at same time there can be early bug in a subroutine that e.g. calculates a sum of values in array, which does not affect other code. But there again, more complicated subroutines (e.g. a sum that makes use of multiple processors) will be able to have errors that stay unnoticed (failing once in a blue moon) while simpler code (straightforward sum loop) won’t, so the errors which took a long while to detect would tend to be inside more complicated code which is harder to fix.
At same time, I have no idea what would be the average ratio between different errors in a select sample of projects or how the time to detect would correlate with expense. And I do not think I need this data because I do not fall for fallacy of assuming causation from correlation and am aware that later-detected bugs come from more complex code in which fixing bugs is inherently more expensive. You can’t infer causation from this correlation.
The management falls for this and a bunch of other fallacies and it leads management to believe that this sort of useless trivia is important science which they can use to cut down project costs, just as the idiot barber’s manager may think that height to head size correlation (inferred via chain of 2 correlations) is what they need to measure to minimize risks of the client getting their skin cut.
When you have a close look at a specific project you have very little use for the average data over many projects, for the projects are quite diverse. When you don’t, you’re like a high powered haircut machine that only knows client’s height.
Nicely put, overall. Your points on the demands of “management” echo this other Dijkstra screed.
However I have to disagree with your claims of “high grade reasoning” in this particular instance. You say “some of the work affects the later work in very clear ways”: what ways?
The ways most people in the profession know are less than clear, otherwise we wouldn’t see all the arguing back and forth about which language, which OS, which framework best serves the interests of “later work”; or about which technique is best suited to prevent defects, or any of a number of debates that have been ongoing for over four decades.
I’ve been doing this work for over twenty years now, and I still find the determinants of software quality elusive on the scale of whole programs. Sure, for small or “toy” examples you can always show the advantages of this or that technique: unit testing, UML models, static typing, immutability, lazy evaluation, propagation, whatever. (I’ve perhaps forgotten more of these tricks than some “hotshot” young programmers have ever learned.) But at larger scales of programming efforts these advantages start being swamped by the effects of other forces, that mostly have to do with the social nature of large scale software development.
The most direct and clear way: I made a decision how to divide up functionality between methods in a class. The following code that uses this class will all be directly affected by this decision. If this decision is made poorly, there will be growing extra cost from the difficulty of use of the class, as well as the cost of refactoring will be growing over time. Cause and effect.
(We do not need to have an agreement which technique, framework, language, etc is the best and which is the worst to agree that this choice will affect the following code and that amending this decision later on will cost more and more. It is straightforward that choice of the language affects the following code, even if it is not straightforward if its bad or good)
Of course at same time there can be early bug in a subroutine that e.g. calculates a sum of values in array, which does not affect other code. But there again, more complicated subroutines (e.g. a sum that makes use of multiple processors) will be able to have errors that stay unnoticed (failing once in a blue moon) while simpler code (straightforward sum loop) won’t, so the errors which took a long while to detect would tend to be inside more complicated code which is harder to fix.
At same time, I have no idea what would be the average ratio between different errors in a select sample of projects or how the time to detect would correlate with expense. And I do not think I need this data because I do not fall for fallacy of assuming causation from correlation and am aware that later-detected bugs come from more complex code in which fixing bugs is inherently more expensive. You can’t infer causation from this correlation.
The management falls for this and a bunch of other fallacies and it leads management to believe that this sort of useless trivia is important science which they can use to cut down project costs, just as the idiot barber’s manager may think that height to head size correlation (inferred via chain of 2 correlations) is what they need to measure to minimize risks of the client getting their skin cut. When you have a close look at a specific project you have very little use for the average data over many projects, for the projects are quite diverse. When you don’t, you’re like a high powered haircut machine that only knows client’s height.