Using experiments to ship faster

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 just delaying the harder parts for later, then it can be considered "fake progress".

If we start out by building the obvious parts we already know how to do - are we really making meaningful progress? or just delaying the uncertainty?

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 can reduce the cost of projects by orders of magnitude.

Because the faster we can locate real problems, and deal with them, 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 writing high quality code.

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. We don't want to spend forever on it.

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 ensure your experiments are successful, here's some 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

If you know how to do it, it's not unknown anymore. For example, if you've built a login form before, no need to spend an experiment on that. Focus on stuff you don't know.

Be 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

Reducing the uncertainty in a project, is more valuable than any TODO you can check off.

And you'll end up shipping projects much faster too!

Happy coding ✌️