Well it seems to me that disciplines become diseased when people who demand the answers can’t check answers or even make use of the answers.
In case of your software engineering example:
The software development work flow is such that some of the work affects the later work in very clear ways, and the flaws in this type of work end up affecting a growing number of code lines. Obviously, the less work you do that you need to re-do to fix the flaw, the cheaper it is.
That is extremely solid reasoning right here. Very high confidence result, high fidelity too—you know what kind of error will cost more and more to fix later, not just ‘earlier error’.
The use of statistics from a huge number of projects to conclude this about a specific project is, however, a case of extremely low grade reasoning, giving a very low fidelity result as well.
In presence of extremely high grade reasoning, why do we need the low fidelity result from extremely low grade reasoning? We don’t.
To make an analogy:
The software engineer has no more need for this statistical study than barber has need for the data on correlation of head size and distance between the eyes, and correlation of distance between eyes and height. The barber works on specific client’s head that has specific shape, instead of inferring it from client’s height based on both correlations and then either snapping the scissors uselessly in the air or embedding scissors inside the client’s skull.
It’s only if barber was an entirely blind rigid high powered automation that only knows client’s height, that the barber would benefit from such correlation ‘science’ - but such automation would still end up killing the client almost half of the time.
However, the management demands science, and in the eyes of management the science is what they have been told in highschool—making hypothesis, testing hypothesis, doing some statistics. They are never taught value of reasoning. They are the barbershop’s idiot manager who demands that the barber uses some science in form of head size to height correlation, to be sure that the barber is not embedding scissors in the client’s head, or snapping them in the air.
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.
Well it seems to me that disciplines become diseased when people who demand the answers can’t check answers or even make use of the answers.
In case of your software engineering example:
The software development work flow is such that some of the work affects the later work in very clear ways, and the flaws in this type of work end up affecting a growing number of code lines. Obviously, the less work you do that you need to re-do to fix the flaw, the cheaper it is.
That is extremely solid reasoning right here. Very high confidence result, high fidelity too—you know what kind of error will cost more and more to fix later, not just ‘earlier error’.
The use of statistics from a huge number of projects to conclude this about a specific project is, however, a case of extremely low grade reasoning, giving a very low fidelity result as well.
In presence of extremely high grade reasoning, why do we need the low fidelity result from extremely low grade reasoning? We don’t.
To make an analogy:
The software engineer has no more need for this statistical study than barber has need for the data on correlation of head size and distance between the eyes, and correlation of distance between eyes and height. The barber works on specific client’s head that has specific shape, instead of inferring it from client’s height based on both correlations and then either snapping the scissors uselessly in the air or embedding scissors inside the client’s skull.
It’s only if barber was an entirely blind rigid high powered automation that only knows client’s height, that the barber would benefit from such correlation ‘science’ - but such automation would still end up killing the client almost half of the time.
However, the management demands science, and in the eyes of management the science is what they have been told in highschool—making hypothesis, testing hypothesis, doing some statistics. They are never taught value of reasoning. They are the barbershop’s idiot manager who demands that the barber uses some science in form of head size to height correlation, to be sure that the barber is not embedding scissors in the client’s head, or snapping them in the air.
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.