Skip to main content

Will it be harder tomorrow? ⏳

A victorious hour glass.

There always seems to be more things to do than there is time available. The backlog is long and growing ever longer. People want their features yesterday. And not only are there features to build, you want to build them right! How can we decide what to prioritize?

It’s easy to feel overwhelmed.

You might find yourself thinking:

  • “Got to get it right from the start, or it will be a mess later.”
  • “If we don’t add caching now, we will never be able to scale.”
  • “We have to build for both web and mobile, or we will lose customers.”

Is it important? #

How can we navigate this? How can we decide what to do now and what to postpone?

A first step (that is easy to say but hard to do) is to filter out the things which are not really that important. It may include things which sound like a good idea, but are not critical to the product. It may include things which feel urgent, but still are not important.

But even after that, the list is still too long. How can I decide where to start?

Will it be harder tomorrow? #

One helpful tool is to ask this question: “Will it be harder tomorrow?

For each feature, consider whether implementing it will be substantially harder if you would do it later.

If it will, you should strongly consider doing it now. Or at least you can make an informed decision if you choose to wait.

But if the feature will not be substantially harder to do tomorrow, you have the choice to wait. This is great! It gives you the freedom to focus on the things that are important now. It helps you avoid premature optimization or generalization.

It is easy to think that adding things will be easier now than later. But often, it is not the case. Especially if you have already solved the initial problem, and thinking about whether to extend the solution or not. If you can extend it today, you can probably extend it tomorrow as well. There is a case to be made for having the context fresh in your head, so maybe it will be a little bit easier today, but that will have to be balanced against the value of other things you could do.

And from a technical perspective, the question “Will it be harder tomorrow?” can help you design a better system. If you find yourself answering yes to the question a lot, think about why. Why is something harder to do later? Is there a way to postpone it without making it harder? Can you design the system in a way that makes it easy to add later?

An example #

I’m currently working on building a new system to distribute content to partners. Developing it will require a lot of work, and there are many features to implement. However, not all features are equal. Some are more important or will have a larger impact on the design.

To get a working prototype of the system, we need to develop a little bit of everything. A walking skeleton, if you will. But we don’t need to implement everything in full detail. As soon as the walking skeleton is up, working on the public interface will be much more important than the internal details. The internals are easier to change later.

A specific example is content caching. While we expect that caching at various levels will reduce latency and improve the user experience, we can add it at any point going forward. In fact, almost by definition caching should be transparent to the rest of the system.

But caching also provides a good example of how keeping it easy to implement tomorrow will affect our design today. For caching to be truly transparent, we need to ensure that any data that will be cached is immutable, that it will never be updated once published. That way we know we don’t have to worry about cache invalidation.

Authentication on the other hand is much harder to add on later. Not only will the system be insecure without it, but our choices will affect the experience of our partners. It is a good candidate for doing early.

A final example is a part of the system which will import data from a legacy system. The data in itself is critical, but as long as the import works there is no need to gold plate it. If the error messages leave something to be desired, we can fix that later.

Wrapping up #

“Will it be harder tomorrow” is not the only factor to consider, but it is a powerful one.

It can split a “very long list of things to do” into a much shorter list of “things I really should do now” and one with “things I can choose to do later”. That makes planning and prioritizing much easier! And not only that, it can help you design your system better!

What will you choose to do tomorrow?