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. I can’t draw cars so let’s just imagine it’s a Jaguar S-type and a Jaguar E-type Code which solves stable problems is usually also stable,…