§Introduction
Do you code a lot? I do. Over the years I’ve written and open-sourced a lot of projects, many of which you can see here.
I’ve also worked on several important projects in companies, bootstrapped startups and other team-based projects, and audited several startups.
Now, a lot of the code I wrote felt right while I typed it – you probably feel the same way when you code. But then later, when I reviewed it, I found plenty of hiccups and gaps in it. And there was also a lot of code that could be polished.
No wonder then that at the end of almost all my early projects, I had to rewrite most of the code. Version 1 (V1) code didn’t really make it into the final product. It had to go out.
§The Problem: Or How I Came Up with the “Trash V1” Rule
The fear of trashing code is certainly the number one reason for the technical debt. However, when you split your code you have way more chances to fail than to succeed.
Often, it’s tempting to spend a lot of time on a piece of code to “make it perfect”. But when you start a project, it’s hard to define perfection in a piece of code. You need the insight that only comes after you finish a version of the code to figure out what would make your code perfect.
If you try to make your code perfect from the start you know what will happen? It will be twice harder for you to trash it even if it’s faulty or just useless, for the simple reason that you’ve invested in it a lot of energy and passion.
I’ve been through all that. Most of my V1 code that I kept back in the early days was just regrets. Usually, I ended up rewriting everything, losing not just time, but adding more retro-compatibility constraints to the code.
You should never do that.
§The “Trash the V1” Rule
Here’s where my rule comes in. It’s a simple rule. It consists of assuming that “nobody (not even me) knows exactly how we want to do the project.” Or, to put it in a different way, that not everybody is aligned with the final expectations for the project.
This rule is essentially an extra step that costs you only a few hours or days but that gives you an extra guarantee. The guarantee that you’ll be able to find the right code when following your roadmap.
At the same time, it’s also a good way to check if the project is interesting. You can consider it as a “trial period” during which you familiarize yourself with the project and understand it thoroughly.
Set this simple rule before you start coding. If you have a team, you should announce it to them before you get to work. This way, you ensure that nobody will lose time on an over-engineered, over-optimized piece of code that in the end fails to deliver the expected results.
Here’s a tip to make sure this rule really works for you: set a short time limit, let’s say 1 evening for a solo project or 2 days for a team project. For bigger projects, up to 1 week should be okay too, but the shorter the term, the better.
And here’s another tip: at the end of the proof-of-concept phase (PoC), even if the project is not yet finished, focus on the core value, on what makes it unique and better than the competition. There’s a chance that your project is already on its way to being “the best piece of software to achieve that thing” in the world.
Now, let’s take a step-by-step approach to implementing this rule. Follow these steps for best results, and to speed up your project too.
§How to Implement the “Trash the V1” Rule
In the beginning, the most important thing is to stop trying to define all the specifications of what is yet an abstract project. Make the project as concrete as possible by focusing on what you know about it and only then define the missing specifications.
§Step 1
Focus on what makes the project unique and write the core specifications. So, what’s special about it? It can be an original feature or a significant difference compared to an existing solution.
§Step 2
Explain the rules to your teammates. Choose any additional constraint (time limit, framework/library/method to use) that can help keep you all focused.
§Step 3
Remind your teammates that everyone should avoid doing early-optimizations and over-engineering.
§Step 4
Code. Do it quickly, with the aim of creating a working version of the product. Don’t waste time on it.
§Step 5
Trash this code. Yes, trash it. Actually, you can just archive the repository in read-only mode and consider manually copying some parts later. It brings you some peace of mind.
Now, you have something concrete and you can write better specifications and a more accurate plan. Technically speaking, you are also able to demo your idea to your coworkers, family, friends, or investors.
§Step 6
Start a new codebase and write the V2 of the code. Ideally, this version should be the one you publicly release.
§Conclusion
I use the “Trash V1” rule for every big or difficult project I undertake. I use it for personal projects as well as for team projects. Even if this rule seems more appropriate for project bootstrapping, it can also be applied to subparts or experiments in a later phase of the project.
Do you fear trashing code? You shouldn’t. Letting go of code you’ve written may not be easy but it’s beneficial.
If you overcome this fear and apply this rule, you’ll actually save time in the long run. In many cases, “Trash V1” will enable you to skip the first required rewrite that usually happens 6 months or 1 year into the life of the code.
So, make this rule a habit – trash version 1 of your code. It may be a bit scary at first, but you won’t regret it.
