Delaying Decisions Until the Last Possible Moment
Tags: devtips, programming, computerscience
Published: 2018-09-25 16:06:16

---
title: Delaying Decisions Until the Last Possible Moment
published: true
description: If you can delay key decisions with your system's architecture, you'll be rewarded with flexibility later.
tags: devtips, programming, computerscience
---

Let's go back in time. A few years ago, I started a project and immediately reached for Bootstrap. I added it to my asset bundle and got to work.

I started writing HTML and sprinkling Bootstrap classes on every element. Before long, I had a handful of views tightly coupled to Bootstrap. I was dependent on it. Being dependent on something isn't necessarily a bad thing. After all, Bootstrap has helped push forward tens of thousands of applications on the internet.

However, there's a problem. I started using Bootstrap before I needed it. Did I need to pick a frontend framework immediately? No. Guess what? Now I'm stuck with it. Unless I want to carefully edit all of my templates or slowly reduce Bootstrap usage to zero, I'm basically stuck using Bootstrap until the end of this application's life.

## Why wait to make decisions

Picking Bootstrap was one of a handful of decisions I made immediately upon the project starting. Worse yet, picking Bootstrap was a non-critical decision turned critical.

In other words, Bootstrap is not a core function of the application. It doesn't run business logic. It doesn't perform key functions of the critical work to be done. However, by making Bootstrap an early dependency, it's now key to the frontend. If I compulsively remove it, the frontend turns into a mess.

Questions like "Should I use React?" and "What CSS framework should I include?" can be left unanswered for awhile. Otherwise, you risk adopting a dependency before it's truly needed.

## Benefits of delaying decisions

One way to help you skip decisions about the frontend is to write tests. Without tests, we're kind've forced to build a minimal frontend to verify our work. When you have to build a frontend, you're tempted to reach for dependencies you might not need.

Starting with tests for business logic can help us avoid the need of a frontend. Instead of using the frontend to verify work, we can run our test suite.

Let's say we're building the comment feature on dev.to. We want to notify the author when a new comment is posted. Without tests, we might create a new post, add a new comment, then check the author's notifications. That might require us to write a large amount of frontend code. It's possible we'd be making a number of decisions before we have a ton of knowledge about it.

If we jump the gun and use React for all of this, we might be stuck with it. We might realize later we didn't really need it, but who wants to go back and rebuild what's already built?

With tests, the story changes. We can ignore the frontend and save it for later. To get started, we'd write a test that creates a new comment. Then, we'd check to ensure the author has a new notification. Verifying our work is running a few tests. No frontend needed.

## This isn't the only way

This is only an example. Delaying decisions about your frontend isn't something you always have to do. If your application is already based in React, it seems clear you'd continue using it. The same is true with Bootstrap. Once you're using it, the default is to continue using it.

However, the spirit of delaying decisions is something to adopt. We might be tempted to think a decision is easy and without consequence, but slowing down is a good idea. "Of course we need to use this library," you might say, only to realize later it's not as great as you thought.

The beauty of delaying decisions is that it can be applied to almost anything. Don't know what you want your backend to be? Build a minimal frontend as you work out the details. Not sure if you want to use Resque, Delayed Job, or Sidekiq? That's cool - you don't need to make that decision early in a project.

## Delaying decisions saves you time

When you make a decision too early and want to change it later, the decision costs you time. If it wasn't a decision that needed to be made, it's a double whammy. Most decisions can be delayed.

If I would've waited to make a decision on Bootstrap, it would've been easy to adopt another framework. You can get away with building a frontend until you actually need a frontend. At the very least, your frontend can be basic until you need it to be fancy.

Try something. When you reach your next decision, don't come up with an answer right away. Let the answer simmer and stew in your head. Do I really need to make a decision on this right now? Can I wait until I know more?

You always have more information tomorrow. Take advantage of that fact.