Designing Software for Ease of Extension and Contraction (1979) [pdf]

Interestingly, to me, good modular design creates both ease of extension and of contraction. In some of my most successful programs (read: met user requirements over an extended period of time with relatively straightforward modifications) it was the modular design that permitted the extensions. But the same structure made it feasible to easily remove old features or migrate them to new programs based on user needs. Maybe the main program was a bit of a Swiss army knife, but we had a customer who only needed a few features. The design made it possible to extract a new program from the old one primarily through selecting which parts of the core (lower layers in this paper) were needed and wrapping them in a new (or simplified) GUI.

But maybe it's possible to do seemingly good modular design which favors extensibility, but fails at contraction/extraction. I had some experiences in my formative (college) years that lead me to want to write things the way I did for those successful programs. This is certainly something that requires exercising. If it weren't being exercised, maybe we wouldn't have been so successful. As in, if I tried to make a good modular design and only 5-10 years later we contracted the program or extracted new programs from it, maybe it would have grown enough cruft to make that a challenge, but extension would have still seemed easy.

As I think about it more, I'm leaning towards the issue being exercising the option of contracting the program. If you only ever extend, it becomes increasingly easy to blur the lines between the layers of the system.