Blog: Rotem Hermon on Coding Changes

How often do applications realistically change?

Applications are a bit like life itself - if they don't change they die. Change is all around us. The customer needs change. The business needs change. The people involved change. Things don't tend to stand, still and your application needs to respond and reflect all these changes. And the rate of change is only getting faster, with the adoption of fast pace practices (Agile) and less rigid infrastructure (cloud). Short cycles and fast reaction are a must to be competitive today - and that means constant change.

What kind of issues arise when an application is not designed for change?

Things start to shake and break. Working on an application in a fast paced environment is like repairing and upgrading an airplane while cruising at a high altitude. If the system is not built for change, you need to start hacking it and placing one patch over another. This just makes it even more breakable. So developing even small things starts to take longer. Changes suddenly have all sorts of unexpected effects that no one predicted. It's harder to test. You start hearing about developers being afraid to make changes because they don't know what will break. That's a good sign that the application went over its change capacity.

Does accounting for change not increase the complexity of the application?

In a way it does. Designing an application with change in mind means, among other things, modularity. So while the complexity of each module might be low in itself, the system complexity as a whole increases. This is balanced, of course, with the complexity you get if making a lot of changes to a system that is not easy to change. So it's an interplay between getting the system to be change-ready in advance and the level of complexity. As always, you want to be balanced. Have the right foundations to allow change while not over-engineering it into a level of complexity that is not needed.

Which architectures should developers look into to make their application more change-tolerant?

Things like Hexagonal Architecture, or Robert Martin's Clean Architecture, are a good start to some of the principles of encapsulating change. Then there are microservices, which actually comes to solve other issues, but of course contribute a lot to making a system more change ready. Juval Lowy has a very insightful view on designing for change in a microservices environment. And eventually all of these ideas are building on some very basic and old concepts of designing code, which we all pretty much apply when coding. It's so much a matter of bringing it into awareness in all levels of system design.