Using stable and evolutionary problems to guide decomposition

One of the questions that I’ve wondered about is how do you choose how to decompose a program into smaller pieces? It always felt like this is largely something you do intuitively, based on experience.

But I recently read an excellent article on Meir Lehman’s Laws of Software evolution, and something finally clicked: You can usually categorize code into two groups, stable (or specified) and evolutionary problems, and you can use these groupings to guide program decomposition. Lehman’s original text also discusses some others, but these two groupings seem like the most useful.

• S-type problems: A stable, or specified, problem is something where we can say with some level of certainty that the problem won’t change.
• E-type problems: An evolutionary problem is something that is likely to change. For example, as a result of a change in requirements.

Code which solves stable problems is usually also stable, meaning you need to change it less. Code which solves evolutionary problems changes more. So if you try to extract stable problems into their own modules, this means you’ll have chunks of reasonably stable code that doesn’t need to change. In a sense, stable code provides a stable foundation, upon which you can then solve evolutionary problems more easily.

For example, at work I’ve developed a JavaScript-based rendering library. Some parts of it have remained mostly unchanged for years, while other parts change a lot. Naturally, the parts which change then need bugfixes, because that’s what happens when code changes. The unchanging parts have been largely bug-free. When I wrote the library, I never thought about stable vs evolutionary problems, but when I look at the code from this perspective, it’s easy to see the value of this model, and how using it when developing something could lead to better results.

What makes understanding this especially useful is that the idea of S- and E-type problems seems universal. It doesn’t matter what programming language you’re using or whatever other technical choices might usually be used as a guideline for decomposition.

I highly recommend reading the article Stable code from Stable Problems, which goes into more detail on this and what Lehman wrote. I’ve read about this subject in the past, but this article was what made the value of Lehman’s ideas click.