Published May 10, 2007 by John
While googling around recently, curious to know of any news of an old friend and methodologist, Jeff Alger, I came across a recent blog post on his methodology, Solution Based Modeling (SBM), and the book that details it, Developing Object Oriented Software For The Macintosh. [Note: while the book is out of print, there is a two part summary of it online.] Andy Dent points out that the principles behind this ancient (1992) approach to software development are still as true today as they were then, and he’s right.
In fact, I would say that the agile principles that are challenging entrenched models today are very much in line with goals that were laid out for SBM:
- results are the only thing that matter
- admit that the team learns as it goes along, and that releases should be based on the most pressing needs at the moment, not a pre-cast schedule
- focus on short iterations to get into a rhythm across all of the activities (analyze, design, build, deploy, test)
- disconnect “phase” of work (analysis, design, development) from “activity” being done
- effective communication is the enabler of it all
SBM went about delivering on these principles in a different way than something like XP or Scrum, with less emphasis on code and more on ways of thinking and working at different levels of abstraction.
But more than anything else SBM did what few others have done in any formal or acknowledged way: they stepped outside of the world of software development to see what smart people in other walks of life were learning about how we think, how creative people solve problems, and how we perceive the world, activities that are part and parcel of building software, and then applied them to the software world.
The company I was with when SBM came out got some training from Alger and then used it on a handful of projects. From a corporate perspective, SBM ended up getting lost in the eventual search for a methodology that could be applied across the enterprise. However, at the level of the individual projects, I can say that the effect was startling. The clients were more satisfied with what they got, and what they got was delivered when they expected it. No eleventh-hour surprises. And I’ll say that the reasons for these come down to the attention that Alger and his partner-in-methodology, Neil Goldstein, paid to the important parts of a software project.
How we interact. Software development is a team sport, and understanding each other well will make or break any project. Any process that talks of “handoffs” is just inviting the kind of thing you get from the game of “telephone”, where a phrase is whispered from one person to another down the line. In the game you can all laugh at how outrageous the result is compared to how it started, but when that kind of breakdown happens on a software project not many folks will laugh.
What SBM brought forward was a process that has the whole team involved throughout. The agile folks know this is important too, and in both approaches it is made easier by having short iterations. No one group goes away for an extended time to do its work. Short iterations demand frequent contact within the team, it is simply hard to avoid. While it may feel different to people accustomed to “the way we always do thing”, when the team looks at the results after a few iterations that go well, a positive feedback loop can start that makes it easier to continue down this path. It also means that any corrections you have to make to the course of the project are small, and smaller is almost always more manageable than big.
How we solve problems.
The assumption of the waterfall model of development (and its named and unnamed variants) is that you can come up with a solution to a problem by following a set of pre-defined steps. But what do you do if you and your team don’t know what the end is going to be, or how exactly to best get there?
By analogy, when you are making a dish for supper, you are going to follow the steps laid out in the recipe, and do them in the order listed. In the end, you will have what you expected, a dish. But how did the person who was coming up with the recipe in the first place go about doing it? They probably didn’t get it just as they wanted the first time. They had a general idea in mind when they started (”something savory, with a light sauce and plenty of vegetables”) but then they had to explore. They might try out a few different sauces to get the right flavor, create a few small portions with a few differences for comparison, and try it out on some friends or neighbors to get some reactions to it. What they are not going to do is get it all right the first time (a waterfall model), or even get it right be taking just one step back at a time (a modified waterfall model). They are going to let their creativity have rein to explore the space of possibilities, and then choose among the options to put together something finished.
Software developers, for all of the engineering background they may have, are much more often asked to create brand new things, even brand new processes, than to create something out of a cookbook. And when you are creating something brand new, you need to explore, not just at the beginning, but to varying degrees throughout. This is no longer that radical of a notion, but it still gets less attention than it needs outside of agile teams, in large part because it doesn’t seem like a process that can be “managed”, and without “managing” it there can be no predictability to the project. As the XP and Scrum folks show, though, it’s entirely manageable. Alger and Goldstein felt so too, and the process built in to SBM assumes that the order in which you do things is irrelevant, at least as far as the ending result; its only effect might be on the time it takes to arrive there, and that can be tracked and managed, but not optimized in a universal way.
How we think about the world.
Part of the early appeal of object-oriented development was that pieces of our programs could be “objects”, implying that we could deal with our intangible programs with a lot of the skills we have for dealing with tangible “objects” in the world. There turn out to be a number of problems with this, such as the fact that good software design with objects doesn’t end up looking like anything related to real-world objects, rather it looks like software with good encapsulation and cohesion.
On a more subtle level, there is the fact that the “objective” view of the world isn’t as useful in all cases as we might think. All of the high-profile object-oriented methodologists took this view as a given, and their approaches reflect it: there are objects in the world that we can all identify and describe objectively; our job for software development is to simply find them.
Alger and Goldstein did some digging into research that has been done in fields like cognitive science and presented some compelling alternatives to apply to the world of software:
- Don’t assume or require that what a programmer wants to call a “railroad track” object in the source code has to match what the client thinks of as a “railroad track” when explaining what they want for a railroad track layout program. They may be related, but they could have significant differences when talking about the system at the conceptual level as compared to the class level. Instead, allow them both to be part of the description of the system, since they are both valid to someone on the team, and provide ways to correlate them to each other.
- Come to grips with the different ways that we might categorize the world, and let that help you understand ways that you might describe the “objects” of a system at the highest level. They drew heavily on the work of George Lakoff, especially the idea of categories laid out in the book Women, Fire and Dangerous Things. The difference between Lakoff’s categories and traditional classification is something like the difference between Newtonian and Einsteinian physics; for a basic understanding of how to categorize something (for example, a “book” object), a simple model usually does a good enough job, but when you need to deal with something less concrete (for example, a “constraint” object), you need a richer explanation of what is going on in our minds.
How we communicate.
In any development project, you’re going to be sketching things that represent the system or the program or parts of it, and how they interact. You are also going to need to do this at different levels of detail with different groups of people. The language that has tried to capture all of this for software development has become the Unified Modeling Language, or UML, a compromise committee-created language that nobody loves but everyone has accepted as the only real choice. It is very expressive for hard-core technical details, but weak for conceptual diagramming. The agile folks tend to chafe against this because they see any design language as a means rather than as an end, and if you can’t express what you want to in the language, then you ditch that language and use what works. Where it can help to solve a problem in a design session, they may use UML, but in sessions with the larger team, you’re just as likely to see informal sketches.
Now, while there could be a rich discussion of what language you use to facilitate and capture information when you are exploring the problem space, my point is not to get into that here. I think that one of the reasons that a lot of teams (agile or otherwise) don’t use the UML for high-level sessions is that it is just not a good visual language. It was designed by techies for techies. Alger and Goldstein, on the other hand, took the novel approach of asking people whose job is visual communication (graphic designers) to help them come up with an effective notation. What they ended up with, the Visual Design Language (VDL), differs from the traditional notations in subtle but very important ways.
To start with, the elements of the language have a three-dimensional look to them, not in any fancy way, just with the addition of a couple of lines. Doing so adds a depth dimension to them, without making them any harder to sketch.
For techies more concerned with precision than richness, the difference doesn’t seem like much, but when you want a language to communicate among everyone on the team, the payoff is big. Which makes more immediate sense?
Some of the other differences fall into the area of suggestions and conventions for using the elements, lessons in communication that are easy to pick and apply to any visual language.
- Use the cultural convention for time sequences that is embedded in your culture. For western culture, that’s a left-to-right flow. The UML sequence diagram takes advantage of that too, but if your culture uses a different convention, use that to harness your reader’s natural tendency for interpretation.
- Use visual cues to draw attention to the part of the diagram that you feel is most important. That can be by relative size of the elements (big implies more important), line weight, or placement on the page (a figure in the center drawing attention as a central concept).
- Keep each diagram digestable, and describe the system instead as a collection of overlapping mini-models. A poster-sized view of your system may make for interesting wallpaper, but for helping communicate about a small chunk of the system, which is what most communication ends up being about, you will do well to stay within most people’s cognitive limits. That usually means following the rule of “seven plus or minus two“, which generally describes how many concepts we can comfortably keep in our head at once.
Of course, these practices, really don’t require the VDL at all; you can improve your UML or ER diagrams by following them. What SBM brought was guidelines for taking advantage of these practices without much effort.
While I wish that SBM and VDL had gotten a little more traction, I’m glad to see that the agile folks have been able to explore these principles further. There is still a lot we don’t know about how to develop software, and I take my hat off to those who are pushing us out of entrenched (and ineffective) comfort zones.