The past few weeks I have been participating in a book study group on Michael Jackson’s Problem Frames: Analyzing and structuring software development problems. Problem frames are a concept that Michael Jackson (the UK software analyst, not the courtroom celebrity) invented to characterize classes of problems that computer programs solve. According to Jackson,

“A problem frame defines the shape of a problem by capturing the characteristics and interconnections of the parts of the world it is concerned with, and the concerns and difficulties that are likely to arise. So problem frames help you to focus on the problem, instead of drifting into inventing solutions.”

Problem frames are lenses you apply to look more deeply at a problem. If you know what type of problem you are looking at, you can ask intelligent questions and make tighter specifications for how your software should behave and how it should interact with things in the world. Being a designer, I’m always looking to solve problems. Yet it is true that mixing up problems with solutions can cause interesting communication problems and disconnects.

Consider this statement from a Canadian farmer about the trouble with daylight saving time: “Chickens do not adapt to the changed clock until several weeks have gone by so the first week of April and the last week of October are very frustrating for us.” OK, I’ve gotta ask, do chickens really understand changed clocks? Of course not. The problem isn’t that chickens can’t adjust to the changed clock. The problem is that farmers’ sleeping and waking habits shift as a consequence of daylight saving time. The chickens still are disrupted, but only because the farmers have adjusted their behavior. Let’s not mix up cause with effect.

Jackson’s book is full of examples that exercise the muscles in your brain that help you untangle cause from effect and explore how much of the real world you have to understand before you can specify how your software should behave. It has been novel for me to take several steps back in order to deeply understand the nature of a problem. Be aware that I have a healthy skepticism for “big upfront analysis” just like I do for “big upfront design”. I don’t think the right approach for me is to spend lots of time deeply pondering problems before I start thinking about solutions. But l hope to apply Jackson’s ideas and deep insights on problems into practical advice and recommendations for those who aren’t keen on formalisms. Stay tuned.