Paradigms and Software Projects

I feel that software projects either try to define and set in stone everything before starting, or they just start and hope to understand things during the course of the project.

In The Structure of Scientific Revolutions, Kuhn talks about how during pre-paradigm periods, different schools can be seen as competing to present a theory or model of whatever the scientific community focuses on. To me, this suggests that in software projects without any up-front planning, or without enough communication between team members, you’ll likely have competing views of the problem domain. And what’s worse is that those views may be largely unarticulated.

As for projects who want to do all their planning at the start, Kuhn’s talk about what happens after the emergence of a new paradigm seem relevant. He writes in the case of the Franklinian paradigm:

What the fluid theory of electricity did for the subgroup that held it, the Franklinian paradigm later did for the entire group of electricians [the scientists devoted to studying electricity]. It suggested which experiments would be worth performing and which, because directed to secondary or to overly complex manifestation of electricity, would not. Only the paradigm did the job far more effectively, partly because the end of interschool debate ended the constant reiteration of fundamentals and partly because the confidence that they were on the right track encouraged scientists to undertake more precise, esoteric, and consuming sorts of work.

Later in this paragraph, Kuhn quotes Francis Bacon as saying: “Truth emerges more readily from error than from confusion.” Projects that proceed using only paper products (diagrams, documents) can’t be sure of the truth. They might feel certain of their assumptions being correct, but not until exposing the software to its users will they know for sure whether they were right. Talk and diagrams aren’t effective in finding out if the customer and the development team are sharing the same vision.

Kuhn’s book suggests that what matters is establishing the fundamentals, a shared paradigm to use his terminology, because a shared paradigm “guides the whole group,” it “sets the problem to be solved,” paradigms “guide research by direct modeling.”

Central in science are experiments. Empirical work. For software projects this means actually producing something and testing it on the users. It’s the articulation of a hypothesis and the experiments to prove or reject it. All over the book, Kuhn says things such as how science is often about bringing “nature and theory into closer and closer agreement.” This is true for software projects as well; it’s not only about giving the customer what he wants, but helping him to find out what he wants. This is not about giving him something and saying “Here’s what you want!” It’s about giving him something, and seeing how he reacts upon it. It gives him as well as you ideas of how to proceed.

Now to another thing: Software development is confused about itself. Kuhn says this is as expected:

The pre-paradigm period, in particular, is regularly marked by frequent and deep debates over legitimate methods, problems, and standards of solution […]. [D]ebates like these do not vanish once and for all with the appearance of a paradigm. Though almost non-existent during periods of normal science, they recur regularly just before and during scientific revolutions, the periods when paradigms are first under attack and then subject to change.

Another thing he makes me think of is the education of future software developers. Richard P. Gabriel has suggested a Master of Fine Arts program for software, which the following passage reminded me of:

[T]he process of learning a theory depends upon the study of applications, including practice problem-solving both with a pencil and paper and with instruments in the laboratory. If, for example, the student of Newtonian dynamics ever discovers the meaning of terms like “force,” “mass,” “space,” and “time,” he does so less from the incomplete though sometimes helpful definitions in his text than by observing and participating in the application of these concepts to problem-solution.

Students must learn by doing, and by studying past achievements. Real achievements.