Balancing Today and Tomorrow

One of the hardest things that any software product company has to do is balance the needs of today with the potential needs of tomorrow. Answers to how the business will scale in the future are largely unknown in the early going, creating the dilemma of either building just what you need for today and not thinking about tomorrow at all or spending a crippling amount of time thinking about what might happen tomorrow and not executing today.

How do you balance the needs of today along with the potential needs of tomorrow when building your product?

Focus on Today

Planning for scale before you know the direction of the company causes an incredible amount of wasted time and money. We affectionately call this “premature scaling.” The last thing any good developer wants to do is to throw away the work they did six months ago because they didn’t adequately plan for success. As a result, there can be a tendency to create additional, un-needed complexity. What does this look like?

• Spending excessive time planning for every possible contingency. “What if we get to 1 million users next week?”
• Spending too much time on architecture drawings and system design and investigating every possible option to solve a problem
• Creating load testing frameworks that stress test your product at 50x your current user base

It’s worth reminding your development team that if the company doesn’t execute today, there is no tomorrow to worry about. Especially early on, solving today’s problems is most critical.

But what about tomorrow?

Allow Room for Tomorrow

Part of building great software is understanding which parts of the system are likely to be under the most stress or are most likely to need to be changed at some point in the future. For example, it’s not likely that you’re going to need to change your user interface to some radical new technology in the near future. Whether you’re using Angular, React or some other framework, chances are you’re going to be ok with that decision.

What is likely is that you may need to change some back end infrastructure as you scale, such as your database provider or perhaps a messaging or email provider.

It is in these points that you build flexibility today to allow you to change your mind for tomorrow. In software these points of flexibility are called abstractions. Let’s take the email example.

In the beginning, you make the choice to host your own mail server because it’s easier and money is tight. Then, as your system starts to grow, you start having issues with your mail server. It’s failing frequently and your tech team is having a hard time keeping it running. You make the decision to move to a new mail service provider like Mailgun or Sendgrid.

In the first scenario, the code is tightly joined (or coupled as developers like to call it) to only sending email using your local server. It’s talking directly to your mail server.

In the second scenario, we’ve created an abstraction called MailProvider, which hides how we actually send email from the rest of the application. This concept is called implementation hiding. Now, anywhere in our application where we need to send email, we simply use the MailProvider and say “MailProvider, we trust that you know how to send email, so here’s an email to send.” The MailProvider can then make the decision about how we’re sending email today and, in the future if that needs to change, the rest of the application doesn’t care at all.

In the first scenario, we would have to rewrite a bunch of code to change to Mailgun. In the second scenario, 99% of our code is unchanged.

While this concept may seem difficult to understand here, it is critical to any system design. By creating points of abstraction, we can move quickly today and not lock ourselves in to changing our minds in the future.

How Do You Know?

How do you, as a non-developer, figure out if the application you’re building has the proper flexibility built in for tomorrow? You can ask questions of your development team like:

• “Let’s say we’re wrong about X (whatever X is). How much code will we have to change if we change our mind six months from now?”
• “If we need to scale this piece of the application, how will it affect the rest of the application?”

If the answers you get are either blank stares or “that’s a lot of work” it might be a good time to have someone help you with design to ensure you’ve got what you need today and have allowed for tomorrow.

Of course, there are inevitably going to be decisions made today in haste that you will pay for tomorrow. It happens in every project, and it will happen in yours. However, you can minimize these events by creating the proper abstractions today.