Migrating from feature to structure

I’ve recently notice that I frequently use a very productive programming pattern. Usually I just take it for granted, but today I’ve decided to call it out, in case it might be useful to others.

When I’m developing new capabilities, I think of them as “features” — things that I’m adding to the outside of the system. They are sort of like adornments, add-ons, things that make the system more powerful or fun to use, but aren’t essential.

Working this way allows for very rapid iteration. If you aren’t changing the core structure of anything, then you can make changes very fast, and you can switch between changing code and the resultant change in experience pretty much instantly. Not needing to “recompile the system” is a big win.

But eventually (in a good scenario) the feature grows powerful and stable enough that it starts to feel like a core capability of the system itself. Then it’s time to move things inward.

Rather than continuing to present the new capability as a feature, after it has matured enough I move it into the core part of the software. So now instead of just being available as an add-on, it becomes available everywhere.

Over time this way of doing things results in an ever more powerful set of tools. And it does so without the risk of suddenly breaking things by constantly adding new stuff that tinkers with the inner core of things.

I suspect that a lot of people who develop code use the same pattern. I wonder whether there is a name for it.

Leave a Reply