Change happens in systems. It doesn’t happen immediately. It doesn’t happen all at once. But if you look at a system over long periods of time, you’ll see changes are made to it. Here are some categories of components that I’ve seen change across many clients. We’ll move from less technical to more technical causes for change.
Business/Process Changes
The most common or easily identifiable change is a process or business logic change. Here’s an example process:
- Author submits article
- System notifies Staff
- Staff notifies Reviewers
- Reviewers perform reviews
- System notifies Staff when all reviews are complete
- Staff publishes article
An example of a business logic change would be to remove/combine steps 2,3 and have the system notify the Reviewers instead of having the Staff involved then. Or you could add a step where the System notifies the Author their article is published.
More difficult changes involve breaking out a step into pieces, such as what you’d need to do to support “not all reviewers have to review the article, just a majority of positive reviews are necessary”.
These changes are high value for the business. With a properly architected system, a programmer can make the change cost similar to the value derived. For a web application, you might need to make a new page, update a form, etc.
Vendor Integration Changes
Systems change because the vendors the system uses change. If you’re pulling data from Facebook Marketing API to decide which articles to feature, you’ll need to update to the latest API versions as Facebook removes access to older versions. Sometimes clients change accounting systems and need to send data in a different format to a different accounting system. Sometimes you might want to try a new technology like Snowflake and send data to multiple warehouses simultaneously. Maybe you switch payment processors.
The value in these changes is lower, but they’re mandatory. Generally they are a required “we have to do this or our system breaks”. Hopefully the changes in vendors technologies will also provide value elsewhere to your organization. The technical complexity here is large – you must identify where all the touchpoints are to that vendor and make sure you’re properly migrating each one. For changes like this, it would make sense to set up an architectural boundary to group the touchpoints together so swapping them is treated like a plugin to your system.
Programming Library Changes
Frameworks update. Frontend and backend web frameworks update all too often! Libraries change, and you need to make sure you can update them without affecting the rest of your application. There are so many libraries your application is built on – choose wisely where you make boundaries here. When CodeIgniter 4 was released, it wasn’t backwards compatible with CodeIgniter 3. That makes for a horrible transition on many parts. The clients aren’t happy because it’s taking their money to simply keep what they already have. The programmers aren’t happy, because… have you ever tried migrating frameworks? You have to change everything. Unless you’ve got some boundaries.
A better approach to make it easier to migrate frameworks (and libraries) is to isolate your business logic from the framework. Then simply figure out how the new framework gets the session data, request body and pass it into your business logic components.
Programming Language Version Changes
When your favorite programming language releases its latest version, and long term support is over for the version that you actually wrote your system in, you’ve got to migrate versions. This is the hardest change to make by far. The way to make it easier is if you have tests written for your code. Try running them with the next version of your programming language. See if there are tools available to automatically upgrade your code. Then, you’ll still need to run your tests, but it’ll save you a lot of busywork.
Planning for Changes
One philosophy in programming is YAGNI – you ain’t gonna need it. Don’t build anything that you aren’t using right now. How do you reconcile that with planning for future change? Are the architectural boundaries and extra time spent writing tests worth it? I would argue that you are going to need tests. You are going to need boundaries. You get to decide where to put the boundaries and write the tests. And in my experience, here is where systems change. If you’re planning on your system running for five or more years, putting boundaries in these places will greatly reduce the complexity of change years down the road.
