How often do you think of how the next generation will perceive your code, and how the decisions you make will affect them? We do not want to leave a mess behind, but how can we design for the unknown?
If you are skilled and lucky enough to build something that launches with success and turns to profit – beware of the flip side where your software becomes an increasing liability to the business or the blocker preventing it from evolving fast enough. In addition to doing the right things we need to be equally concerned about doing things right.
Personally, I think about the next generation all the time. With every piece of code I write, I consider what I can do now to make it easy enough for them to grasp it, isolate it, test it, change it and most importantly; replace it.
Readable code will only take you so far. Code that is easy to change in terms of features and bug fixes is not enough to make the system last over generations of technology. Generation changes in technology will happen faster than you expect, and modern platforms, infrastructure and paradigms will become outdated long before your business.
Mind The Difference Between Generational Code And Timeless Code
One failsafe way to prolong the expiration date of any code is to protect it from infrastructure. In other words, make sure your most valuable code (the business related) is protected from your hipster frameworks that do magic to your solution (the infrastructure). Don’t get me wrong, infrastructure is swell. As software craftspeople we might even call it our personal core business. But it is very much contemporary, so don’t mix it into the code that matters in the long run.
As an example, consider a domain model that is defined using a persistence framework. The system is likely to outgrow the framework before it outgrows the domain model, so basing one off the other is not a forward compatible idea. Or if your business logic is tied into a platform dependent transaction manager, it is bound to retire long before the logic itself has lost its meaning.
If we decouple the code that has the domain knowledge from the stuff that goes around it in order to actually deploy it and run it, serve requests, persist data, integrate, etc., it enables us to safely upgrade the system when parts of it become outdated. We will never get stuck with a tired black box where no one dares making changes and that seems just too painful to replace.
Design For Retirement
So if you haven’t already, start thinking of the next generation of your software, of craftspeople, of technology. Think of how to move to the next generation while designing the current generation. Use your imagination, or use mine; timeless, no-bullshit business code supported by disposable pieces of infrastructure.