The Image of the Scientist and the Programmer

The following is from The Structure of Scientific Revolutions:

In [some] cases […] considerable time elapses between the first consciousness of breakdown and the emergence of a new paradigm. […] Faced with an admittedly fundamental anomaly in theory, the scientist’s first effort will often be to isolate it more precisely and to give it structure. Though now aware that they cannot be quite right, he will push the rules of normal science harder than ever to see, in the area of difficulty, just where and how far they can be made to work. Simultaneously he will seek for ways of magnifying the breakdown, of making it more striking and perhaps also more suggestive than it had been when displayed in experiments the outcome of which was thought to be known in advance. And in the latter effort, more than in any other part of the post-paradigm development of science, he will look almost like our most prevalent image of the scientist [emphasis mine]. He will, in the first place, often seem a man searching at random, trying experiments just to see what will happen, looking for an effect whose nature he cannot quite guess. Simultaneously, since no experiment can be conceived without some sort of theory, the scientist in crisis will constantly try to generate speculative theories that, if successful, may disclose the road to a new paradigm and, if unsuccessful, can be surrendered with relative ease.

This reminded me of the following, from Paul Graham’s Hackers and Painters:

I like debugging: it’s the one time that hacking is as straightforward as people think it is. You have a totally constrained problem, and all you have to do is to solve it. Your program is supposed to do x. Instead it does y. Where does it go wrong? You know you’re going to win in the end. It’s as relaxing as painting a wall.

This in turn reminds me of what Kuhn says about normal science as puzzle-solving, because bugs, as puzzles, always have solutions. Kuhn writes: “Though intrinsic value is no criterion for a puzzle, the assured existence of a solution is.”

Kuhn discusses the question of what motivates scientists when the aim of normal science isn’t “unexpected novelty.” He uses the puzzle-solving metaphor to indicate that about “achieving the anticipated in a new way,” that it’s about “ingenuity or skill in solution.”

There’s a link between science and software development in that scientists and programmers are different from the prevalent image of them. I’ve been thinking about whether this can be shown using Kuhn’s notions of normal and extraordinary science. But I’m not sure yet.

In science, the modus operandi is what Kuhn calls normal science, which is research based on a paradigm. It’s not about invention, but of researching things anticipated by it, of articulating it. In software development, however, there seems to be more inventing going on. Software projects definitely need a strong shared vision, which is an important function of the paradigm in science, but for each feature to be implemented, innovation is required (albeit innovation within the constraints of the shared vision, metaphor, paradigm, or whatever). So there are commonalities, but I’m not sure of how far they go.