Several years ago, I was working with a new client.
They said all the requirements were ready to go, and building should start right away.
So we started work.
A few months in, we discovered a big blocker. A key API we planned to use simply didn't exist.
In the end, we had to scrap a lot of high-quality work. It cost the customer quite a bit of money and time.
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, 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? or is it just "fake progress"?
Because just checking off on busywork won't reduce the overall uncertainty of the project. It just delays the more challenging stuff into the future.
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:
- Collect a list of unknowns. These are things you think will be hard, or haven't done before.
- Prioritize the list to tackle the most critical issues first.
- Estimate how much each experiment will take. For example, 1-2 hours each.
Then for each experiment:
- Build a minimal solution, being mindful of the timebox.
- Capture the result. Either in a GitHub repo or a code snippet on your machine.
- 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 ✌️
Top comments (2)
Loved the part "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.". specially when dealing with unexpected ways users operate a system / program.
Thanks Vitor 🙌🤘