Positivism and Software Engineering

According to the positivist line of thought, a good scientific theory should be based on a few postulates and infer useful conclusions from those postulates using formal logical or mathematical constructs. It the theory is correct, it should be possible to verify its conclusions empirically. Positivism contrasts with the aristotelian approach, which was to infer the natural laws by pure reasoning instead of empirical observation. It wasn't until Galileo that empirical evidence started to be used to validate scientific theories.

Because of the way positivism works, under this approach it is never possible to prove that a theory is correct. It is only possible to increase the confidence on a theory through empirical observation. The more predictions of the theory are proved by empirical observation, the more confident we get in the theory. But it is possible to prove a theory wrong, by providing one single empirical example of when the theory's conclusions don't hold. If a theory is proven wrong, it becomes necessary to verify the logical inferences for errors, or go back and choose a new set of postulates. Strictly speaking, by this definition Newton physics is incorrect, since some of its predictions are incorrect in edge cases of mass or speed, but it is a good enough approximation for a large class of problems.

Lets take the special theory of relativity as an example of how the positivist approach works. Einstein started from 2 postulates. One was the principle of relativity, that states that the laws of physics have the same form for any frame of reference in uniform motion, enunciated by Galileo in 1639. The other postulate was that the speed of light, not time, is constant. Then, using mathematics, he inferred many useful conclusions that could all be verified empirically later. Positivism puts a strong emphasis on empirical evidence.

Einstein didn't take his postulates out of a hat. Observations had already shown in 1887 that the speed of light was constant, which contradicted the prevailing theory of the Ether. Einstein's great merit was to accept this empirical evidence as truth and use logic and mathematics to calculate what were the implications of this fact.

Well, this blog is not about physics, so how does this relate to software engineering?

For the sake of illustration, we could trace a parallel between the software development process and the scientific method. In software we start with requirements, which would correspond to the postulates of a theory, go through the process of building the software using good engineering practices, that would correspond to inferring conclusions from the postulates through logical inference, and end with the system satisfying the user needs, which would be like having the theory's conclusions being proven by empirical evidence.

Waterfall approaches are like the aristotelian method: after starting with a set of requirements, there is no empirical verification of the validity of the results until the system is put into production. Building a system that doesn't satisfy the user needs through a waterfall approach is the software engineering equivalent of the geocentric model of Aristotle.

Iterative approaches, on the other hand, employ a positivist approach. The process starts with requirements, and the results of combining the requirements to the engineering practices are constantly validated empirically. When the assumptions turn out to be wrong, or when the reasoning represented by the software engineering practices employed turns out to be incorrect, the result is a system that doesn't satisfy the customer needs.

This is why it is important to have frequent feedback, which is obtained by having short iteration cycles. With constant feedback, it is as if the theory gets constantly validated by empirical evidence.

Of course, software engineering has complications that physics doesn't have. As far as we know, the laws of physics don't change, but requirements do. It means that a system that satisfied the requirements in the past may become obsolete. Also, developing a theory from postulates in physics has to be done through strictly formal logic and mathematics. The software engineering equivalent would be to use strictly formal methods for architecture, design and coding. This approach is not possible or desirable in the vast majority of the circumstances because it would add an enormous overhead to the software development process.

Even risking getting into the field of pure speculation, we could extend this parallel between software engineering and positivism further and get to the conclusion that great software, like great scientific theories, require great people with the intelligence, the knowledge, and the insight. Einstein had the intelligence, had the knowledge of the latest scientific breakthroughs of the time and the insight to put it all together and come up with the theory of relativity. To the same measure, James Gosling had the knowledge of developing languages and compilers, the intelligence and the insight of putting some of his best ideas together in the Java platform. Bram Cohen had knowledge of peer-to-peer protocols when he developed BitTorrent.

Just like the western science made a great leap once we stopped using the aristotelian method, software engineering also got a great benefit from adopting a cycle of feedback.