Problem Frames and an Eager Designer
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,
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.
"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.
posted by Rebecca Wirfs-Brock at
1:11 PM
2 Comments:
I think Jackson's ideas are fantastic and his writing style is so clear that I was easily convinced. I didn't get the feeling that he is advocating "big upfront analysis", just "some upfront analysis," stopping to consider the problem that you are trying to address with a software system.
To me the biggest drawback with problem frames is that it's not quite mature enough if you do want to perform "big upfront analysis." When trying to use the diagrams I found a number of cases where I knew exactly what I wanted to express, I just couldn't figure out the proper way to put it in the diagrams, and the book isn't formal enough about the notation to be of much help.
Torsten-
I am still exploring problem framing and getting better at it. Since I wrote this post I've been working with a couple of colleagues on framing a known problem (email) and seeing what frames and concerns and requirements there are in the problem of supporting an email client. This has been a good exercise in seeing and framing.
I think that Jackson's ideas get you more deeply focused on undertanding what the problem is..in contrast to, say, writing functional and non-functional requirements and usage descriptions (use cases). Especially use cases. They aren't so much requirements as an upfront "design" specification of the desired interactions between an actor and the machinery you are building. I still like use cases more than Jackson seems to like and have even found that knowing what frame concern this use case is touching upon, helps me write better use case descriptions and ask more probing questions.
I have been finding that the diagrams are useful, but even more useful are the sets of descriptions that you come up with (and questions you start asking about domains).
I'd be interested in hearing about the kinds of things you couldn't express in a frame diagram.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home