Crystal balls and clairvoyance: Future proofing in a world of inevitable change

The idea of future-proofing your code is one which perennially pops up in conversations about software program. It sounds magical—who wouldn’t wish to make your code impervious to the long run?

In fact, the fact is way much less rosy and far messier.

On this article, I’m going to debate what I believe folks imply by “future-proofing,” the way you may be capable of accomplish it, and when and why it could be a nasty selection.

How does one “proof” one’s “future?”

You’ll be able to consider future-proofing extra precisely as change-proofing. We are able to outline it as:

“Making a design, structure, or programming resolution that enables for future modifications to be simpler to handle, take much less time or end in fewer modifications to the general code.”

These modifications can fall into quite a lot of totally different classes:

  • Adjustments to scale – the venture has to do extra of the issues it’s doing, whether or not meaning dealing with extra visitors or work objects, processing them sooner, and so forth.
  • Adjustments to necessities – new data has entered the enterprise (or has entered the engineering workforce from the enterprise) and now the system wants to vary to accommodate them.
  • Adjustments to know-how stack – switching to a unique information retailer or programming language, for instance.
  • Adjustments to integrations – the venture wants to speak to a brand new third-party utility, both on high of or as a substitute of an present one.
  • Adjustments to schemas – we wish to change the fields that outline our information objects.

Ought to I keep or ought to I develop?

The primary subject with future-proofing is that it runs slap-bang into one of many central tenets of software program engineering: YAGNI, or You Ain’t Gonna Need It

This precept states that till you really know you’re going to have a change, you shouldn’t code your software program in a manner that anticipates that change. Violating this precept leads to bloat, complicated and pointless abstractions that make the code tougher to know, and infrequently mounds of tech debt.

Nonetheless, in case you by no means forged your eyes to the long run, you actually can run into points the place just a bit additional bit of labor upfront might have saved you months of it down the highway.

So… must you future-proof your code? The reply, as with virtually all the things in software program, is, “it depends.”

I see this as a spectrum of types:

Each state of affairs is exclusive, in fact. However some sorts of modifications are a lot much less prone to deserve future-proofing, whereas in others, the additional work is extra prone to repay and (simply as importantly) not end in important downsides.

Future-proofing methods

Normally, any time we wish to shield ourselves from future modifications, we might have interaction in considered one of two methods.


Modularization is the act of splitting your code up into smaller chunks. Each piece of software program has some degree of modularization—in any other case, your code would include a single huge file that had nothing however unrolled capabilities and primitive sorts. (These applications do exist, however nobody of their proper thoughts needs something to do with them.) 

Growing modularization lets you isolate your modifications to a single module, and/or to extra simply swap modules out for one another. 

You may as well have modularization at totally different ranges. Extracting code right into a operate is an easy act of modularization that hardly ever has a draw back till you’re on the level the place your capabilities are so small and quite a few that they’re exhausting to maintain observe of. Nonetheless, you’ll be able to extract issues into a category, a sub-application, a microservice, or perhaps a separate cluster; and at every degree, whereas the isolation and adaptability goes up, so does the cognitive and administrative overhead of managing your totally different parts.


Abstraction is the psychological mannequin you’ve got of the elements of your code. A module, operate, class, and so forth. with low abstraction (or greater specificity) extra intently fashions the motion it takes or object it represents. A factor with greater abstraction brings your reasoning up a degree. For instance, as a substitute of your code working with Vehicles, it might work with Autos. That manner, in case you ever want to begin dealing with Bikes, the change vital to take action is mitigated by the truth that you had been by no means actually speaking about Vehicles to start with.

The upper you go together with abstraction, the extra versatile you make your code, but in addition the tougher it’s to know. Everybody is aware of what a Automobile is, however once you begin working with Autos, it turns into harder to work with Automobile-specific issues like booster seats and steering wheels. And in case you maintain going greater up the abstraction tree, you may end up coding round Transportation, ManufacturedGoods, even plain previous Objects, and have a really exhausting time determining replenish your tank.

Varieties of modifications

Lets undergo every of the kinds of modifications I listed above. For every, I’m recommending the place on the spectrum your future-proofing efforts may lie. Normally, I will likely be making use of these recommendations for when you’ve got no present indication that the change will occur. Because the change turns into extra doubtless, you’d transfer additional in direction of the left facet of the road.

Adjustments to scale

Making your code and structure strong and in a position to deal with no matter you throw at it’s a core side of design. Nonetheless, a part of that structure and design needs to be what sort of visitors you count on it to have. The upper scale it’s a must to deal with, generally, the extra advanced your structure must be.

Making a easy app that’s designed for use by a handful of inside customers could possibly be executed by way of a Rails or Django utility with a minimal of JavaScript, for instance. However in case you want to have the ability to deal with hundreds or thousands and thousands of concurrent customers, that’s simply not going to chop it. You’re going to want lightning-fast companies or micro-services, horizontal scaling and auto-scaling, and possibly a extra responsive front-end and extra tailor-made and sophisticated caching mechanisms.

Over-architecting all of this upfront when you haven’t any anticipation of your app really scaling to that dimension is flagrant YAGNI. In truth, constructing your system intentionally to your present scale even when you understand you could have to rewrite it when the dimensions modifications is a wonderfully legitimate technique, generally referred to as sacrificial architecture.

Having stated that, there are some scaling issues you need to consider. Leaving in plenty of N+1 queries or having unnecessarily giant or frequent requests is dangerous engineering follow throughout and can depart a nasty style in your customers’ mouths—no matter what number of or few they’re.

Adjustments to necessities

This case (the place your code has to vary or add to its habits) is the toughest one to guess at, in addition to the one most certainly to occur.

It is a case the place normal modularization will help you, however I’d advocate in opposition to making an attempt to prematurely add abstraction to your code.

Particularly, if we’re speaking about enterprise guidelines, isolating the foundations themselves in a manner that makes them straightforward to check and alter is an general good follow.

As a easy instance, right here’s some code working with a product that has some guidelines round what a sound product may be thought-about: if product.value >= 0 && !product.title.nil?

Merchandise could be saved from many alternative locations in your utility. Slightly than the calling code checking these enterprise guidelines, we will extract them to their very own methodology:

class Product
  def legitimate?
    self.value >= 0 && !self.title.nil?
finish if product.legitimate?

We are able to even go additional and have a separate class or module that handles this test:

module ProductValidator
  def self.legitimate?(product)
    product.value >= 0 && !product.value.nil?
finish if ProductValidator.legitimate?(product)

These are comparatively minor modifications and maintain your code clear and simply testable, and may isolate additional modifications of this type to the one place. 

The important thing phrases are “of this type”, nonetheless. If the necessities modifications contain utterly altering how the habits of a function acts, or including new options, that’s the place you wish to begin placing your foot down extra firmly on the YAGNI facet of issues and solely constructing what you really know.

Let’s think about that your product may be bought:

class Product
  def buy
    # contact the acquisition service and full transaction

Wait a minute, you motive. We’d finally develop into not solely shopping for merchandise but in addition promoting them! Possibly renting them? We should always summary this out:

class Product
  def perform_action

class PurchasableProduct
  def perform_action
    # contact the acquisition service and full transaction

That is traditional YAGNI over-abstraction. Folks studying your code gained’t see you buying a product, you’re “performing an motion” on one thing that resolves to buying. 

You don’t have any motive to consider that your small business really will develop into additional operations. You’ve launched a degree of abstraction that removes your code one additional step from what’s really occurring and what’s being modeled.

Adjustments to know-how stack

I’ll come straight out and say it—there’s simply no good motive to construct your app in a manner that you just plan to finally change your primary know-how stack.

That is clearly virtually unattainable to do from a programming language perspective. The one manner you can present extra isolation is to go additional into microservices—which could make sense from an structure perspective, however not from a future-proofing one.

As for information shops, nobody—nobody—really modifications their database from MySQL to Postgres or vice versa. In the event you’re utilizing an open-source or open-standards manner of interacting along with your information, go all into it and don’t look again. At this level, the similarities far outweigh the variations, and in case you do want to change for no matter arcane motive, you’ll want a full regression suite anyway to verify nothing else breaks.

(Word: This level is commonly used to discourage the usage of ORMs. I believe ORMs produce other superb benefits, however the capability to change information applied sciences is just not a sensible argument for his or her use.)

Adjustments to integrations

On this case, we’re nervous about having to vary how we discuss to some third-party utility. These companies can present issues resembling metrics, tracing, alerting, logs, function flags, object storage, deployments, and so forth. On this case, it’s good to have the freedom to vary who you’re doing enterprise with primarily based on price, function set, ease of use, and so forth.

I’m most inclined to make sure that we have now abstraction and modularization round integrations. In lots of circumstances, these third-party purposes may be pretty simply switched out for one another. When you’re offering metrics or tracing, for instance, the abstractions and concepts are very shut to one another no matter which supplier you’ve signed up with.

What I favor doing is constructing a facade round any code that should discuss to a third-party system. Usually to maintain issues easy, it is a wrapper across the API of no matter supplier I’ve chosen, which exposes all of the performance essential to function.

This facade usually takes simply a few days to construct (if there isn’t already one out there) and can be utilized in no matter venture wants it. I’ll usually add a set of workforce or firm defaults that almost all intently match our commonest use case in order that new tasks don’t have to determine it out for themselves.

This facade lets you keep away from vendor lock-in by not tying your programs to any particular supplier—however the overhead is sufficiently small that it shouldn’t confuse you or your teammates.

One factor that’s essential is to mean you can get away of the facade by accessing the inner consumer or API if vital. In the event you’ve chosen your supplier due to particular options that have to be used, then you definately shouldn’t have to tie your arm round your again to stop you from utilizing them. Nonetheless, it signifies that in case you do find yourself switching your supplier, you don’t must make any modifications to the “regular” case—you solely want to take a look at code that accesses the inner consumer or API and focus your work there.

Right here’s a tough approximation of a function flagging library we constructed for inside use:

module FlippFlags
  def backend=(backend)
    self.backend = backend

  def consumer(config)

class FlippFlags::Backend
  def initialize(config) # it is a Ruby model of a constructor, i.e. the "new" key phrase
    @consumer = ... # initialize the precise consumer
def enabled?(flag, person)
    @consumer.enabled?(flag, person)

  def internal_client

# utility code
FlippFlags.backend = FlippFlags::MyFlagProvider
consumer = FlippFlags.consumer(my_config)
consumer.enabled?("flag_name", user_object) # true or false

Right here you’ll be able to see that the one change you might want to make is to change the backend that’s handed into the library, and it seamlessly switches to a unique supplier—or perhaps even an inside class that acts the identical manner! In any other case, you employ the consumer precisely the way in which you’d use the inner consumer, however with out tying your code on to that implementation.

Adjustments to schemas

The form of our information displays our understanding of it. As we acquire extra understanding, we regularly wish to change its form. This might imply including or eradicating fields, altering area sorts, default values, and so forth.

Making our information schemas backwards and forwards suitable is feasible by following some easy guidelines. Applied sciences resembling Avro and Protobuf specify these guidelines and have constructed them into their tooling. In the event you’re not utilizing these instruments, although, you’ll be able to “soft-enforce” related guidelines everytime you change your individual schema to make sure it’s unlikely that your modifications will break no matter will depend on your information.

Having stated that, there are circumstances the place you merely can’t observe these guidelines—and that’s okay! That is once you specify a migration path to go from the previous information to the brand new information. However the guidelines make it so that you shouldn’t have to observe that onerous course of for each single information change you undergo.


Future-proofing is just not essentially a purpose of software program improvement a lot as one of many many “ilities” that have an effect on your design. Overcorrecting on this spectrum can result in pointless work, tech debt, and complicated abstractions. Discovering the candy spot, although, can prevent effort and time down the highway.

Tags: future-proof, software architecture, software engineering

More Posts