Lava Flows, Swiss Army Knives, and Boat Anchors for the rest of us

I’ll be the first to admit that I’m an object geek. But sometimes good ideas from the object community get lost because they are wrapped up in the mystique of objects. Consider the architecture anti-patterns described in AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis or the Portland Pattern Repository.
The purpose of an AntiPattern is to document a bad solution to a common problem, explain how people can slide into an AntiPattern, and mention ways to avoid or remedy it. The point isn’t so much to say “don’t do this” as it is to say “you probably don’t even realize that you’re doing this, but it doesn't work, and here are some things you might do to fix things.” In a recent workshop I conducted for architects working for a state agency, I presented the ideas of anti-patterns to this veteran group of developers. We had a great time identifying anti-patterns they encounter and deal with on an ongoing basis. Most of these architects were not using object technology…but they could spot good decisions gone bad when they saw them. We discussed several examples of Lava Flows, why they occurred, and why sometimes it may not even be a good idea to clean ‘em up. What if your code is subject to changing legislative regulations? Arguably, it may be easier to leave in some code than always be shuffling things around. Especially if you are living with a shrinking budget and staff. On the other hand, if you can cut out bad practices and eliminate confusion of why that “three hundred byte record” is there, removing a lava flow can make it easier on the architect who doesn’t repeatedly explain how to step over it to new staff.

I’m on the look out for object biases in the way I talk about design. I’m hoping to bridge the divide between “those in the know” and “those in the know who use objects.” We have much to learn from each other.

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,

"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.