While reading The Structure of Scientific Revolutions, I came across this
It is no criterion of goodness in a puzzle that its outcome be intrinsically interesting or important. On the contrary, the really pressing problems, e.g., a cure for cancer or the design of a lasting peace, are often not puzzles at all, largely because they may not have any solution. Consider the jigsaw puzzle whose pieces are selected at random from each of two different puzzle boxes. Since that problem is likely to defy (thought it might not) even the most ingenious of men, it cannot serve as a test of skill in solution. In any usual sense it is not a puzzle at all. Though intrinsic value is no criterion for a puzzle, the assured existence of a solution is.
We have already seen, however, that one of the things a scientific community acquires with a paradigm is a criterion for choosing problems that, while the paradigm is taken for granted, can be assumed to have solutions.T.S. Kuhn, The Structure of Scientific Revolutions
I find it thought provoking as well to think about how that mindset (interesting puzzles have solutions) explains actions taken in a software group. I often see teams or individuals going off into “la-la land” of technical work because there is, within the paradigm of computer science, a puzzle that can be solved. With some more performance analysis, some more network packet tracing, some more unit tests the last bug can be found and resolved.
The problems of “what does this software need to do for its user” appear, from the paradigm of computer science, to be unsolvable. People are not well defined, they don’t stick to one way of thinking. There are too many different customers. Therefore any “solution” isn’t really a solution, it is an almost arbitrary decision that can’t be either right or wrong. Kuhn continues
… Other problems, including many that had previously been standard, are rejected as metaphysical, as the concern of another discipline, or sometimes as just too problematic to be worth the time. A paradigm can, for that matter, even insulate the community from those socially important problems that are not reducible to the puzzle form, because they cannot be stated in terms of the conceptual and instrumental tools the paradigm supplies.
The focus on the problems of the paradigm can be beneficial for scientific researchers as it keeps them focused on advancing the paradigm in which they work. We work-a-day software developers, however, are generally not scientific researchers. So we have to ask, is the devotion that puzzle-seeking produces advantageous in a software development context?
Like so many questions that evoke a hand-wavy “context”, the answer has to be yes and no. Yes, puzzle-seeking creates that drive to produce better functioning software that is fast, doesn’t crash, and works as the developer intended. No, puzzle-seeking wastes time and effort on problems that don’t matter to the consumers of the software. Both answers are right and yet neither is complete. Sometimes it is correct to seek that puzzle and sometimes it is a waste. How do we manage this ambiguity?
We manage it by creating another paradigm around the paradigm of computer science. This is the paradigm of any individual’s or team’s “software development process”. The process paradigm gives shape for new puzzles to solve and rules by which we can admit certain puzzles and omit others. For example, XP uses an on-site customer role on the team in order to provide a “correct answer” for what needs to be built for the users. The on-site customer changes the “metaphysical” questions of user needs into problems that have solutions within the paradigm of the team.