Using experiments to ship faster
Tags: productivity, webdev, programming
Published: 2024-07-02 16:47:00

---
title: Using experiments to ship faster
published: true
description: Eliminate the all the hard stuff early.
tags: productivity, webdev, programming
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/el4tjgo2h58m6bb8wy1m.png
published_at: 2024-07-02 16:47 +0000
---

Has this ever happened to you?

You're eager to start coding, so you open your editor and start smashing the keyboard. After a few weeks something unexpected happens, you encounter a major blocker.

Now you have to rework the codebase to get around the problem and a lot of high quality work gets scrapped.

This is very expensive and wasteful and happens all too frequently. But there is a way to reduce the chance this happens.

## Avoiding "Fake progress"

When a project starts, there can be pressure to show fast progress.

But unfortunately, not all progress is equal.

Quick progress might make your stakeholders happy early on. 

But at what expense?

If it's at the expense of completing the project, or long delays later, then it can be considered "fake progress".

If we start by building the plumbing, the obvious and boring parts we already know how to do - are we really making meaningful progress?

Just checking off on busywork won't reduce the overall uncertainty of the project. It just delays the more challenging stuff into the future.

What if we could change that?

## Finding the Real work

Meaningful progress comes from solving difficult issues as early as possible. This is real work. It has the potential to reduce the cost of projects by orders of magnitude.

Because time is very precious, the faster we can locate real problems, the more meaningful headway we'll make.

What we need is a way to locate the biggest unknowns, frictions, and blockers as early as possible.

## Improving work with experiments

One solution is to make a list of the hard parts (aka "unknowns") and experiment with those before you start building the solution.

These experiments are great, because with just a small amount of work they can remove large uncertainties from the project. They allow us to encounter uncertainties as early as possible, and eliminate them before they become costly blockers.

Instead of starting a project by writing code in a complex code base and wasting energy on integration and quality. Experimenting allows us to test problems in isolation, without the cost of integration. This keeps re-work low, because we're not undoing complex production code written at a high quality bar.

Once most of the unknowns are resolved, coding becomes a lot easier. It's just a matter of connecting the discovered solutions together, just like snapping together a bunch of LEGOs.

## How to experiment

Next time you're starting a project, do this:

1. **Collect** a list of unknowns. These are things you think will be hard, or haven't done before.
2. **Prioritize** the list to tackle the most critical issues first.
3. **Estimate** how much each experiment will take. For example, 1-2 hours each.

Then for each experiment:

1. **Build** a minimal solution, being mindful of the timebox.
2. **Capture** the result. Either in a GitHub repo or a code snippet on your machine.
3. **Document** the solution or any caveats encountered.

Once you've worked through your list, and assuming you haven't encountered any major blockers, you're ready to start building! yay

## Finding success

To make sure your experiments are a success, here's a few things to be mindful of:

### Be careful of time management

Don't overdo it. For a 6 week project, a good number of experiments is 10-15. These should take 1-3 days to finish. It's important to timebox these.

### Long experiments are bad experiments

Keep your experiments small. Break them into smaller chunks if needed. If they're taking too long, it could be a tell that your project is too big and that the scope should be reduced.

### Don't experiment with obvious things

For example, if you've built a login form before, it's not an unknown for you anymore. Don't spend time on it. Of course, if you've never used OAuth before, then building a OAuth integration is worth an experiment. What's unknown depends a lot on each developers's own experience.

### Be very careful when re-using an experiment

Sometimes it can helpful to build a series of experiments, where each one depends on the code of the last, but sometimes it's not. Remember to always consider what the integration cost is. A key point of experimenting is avoiding the cost of connecting parts together.

### Keep the quality low

Don't write clean code. Don't write DRY or SOLID code. Don't write tests. The only thing we want is a working solution. It can be super ugly. Worry about quality later, when you start building.

## Conclusion

A great way to conserve energy, is through early experimentation.

By dealing with uncertainty at the start of the project, the danger of encountering large blockers later is greatly diminished.

This eliminates re-work, unexpected costs, and creates a more enjoyable and calm development experience.

Happy coding ✌️