You will hear it from almost every developer: “I could do it better (and faster)”. Refactoring or rewriting an application is developer porn. You explore new technologies, update your stack, redefine the architecture… all these excite our reptilian brains. So great, let’s rewrite the application! But wait… we are still trying to nail our product/market fit, we are still growing the company, we have a legacy application running, we have a customer expecting updates… are we really doing this?
Owning the code base
The Visible 1.0 code base was over 1.5 years old and had been written and maintained by different contract developers to build the prototype while we searched for product/market fit. The code was ok, it worked, but none of the contractors were full time employees of the company. We faced a big challenge of building an engineering team of 3 or 4 people that owns the codebase just as we started to get validation that we were on to something.
Our team was aware and knowledgeable of the technical decisions that were made in Visible 1.0 but there was very little documentation; as to be expected in an MVP. Whether we would have started from scratch or tried to improve the existing code, we needed to know the entire code base through and through to onboard new team members. Additionally, it is definitely easier to document and know the code you write than the code you read. And it is true for every recruit, so the gain here is multiplied by the size of the team. Rewrite 1 – Reuse 0
Running the business
This was the biggest concern surrounding a rewrite, no question. How could we run the business during the rewrite when we have customers relying on the existing version? It was out of the question for the engineering team to support the old version while creating the new one. It would have meant twice as much work and supporting two versions is never fun. As a result of this decision, the company would be effectively split in two, the business team would keep working with the legacy software (supporting existing users, getting new ones) and the product team would develop the next version. Having two separate teams isn’t ideal when you are trying to build a united company! We actually underestimated the impact it can have on both the morale of the business team, waiting on the next version and on the engineering team, whose stress level keeps growing as time goes. Rewrite 1 – Reuse 1
Managing expectations
“When a developer gives you an estimate, multiply it by 2 or 3.” You are really putting the entire business in a sort of limbo out of which you hope to get out as soon as possible. There is always the battle between unrealistic deadlines and overly conservative ones. Everyone wants to release as soon as possible but a rewrite will always include unexpected bugs and problems. The schedule will slip and the more it does the more the tension builds. I can’t stress how much a full rewrite is a gamble and you must take that into consideration. Ask yourself, what if the 3 months become 6? 7? 8? It is an expensive decision for an early stage company, make sure to consider the worst case scenarios! Rewrite 1 – Reuse 2
Investing in the future
The last thing we wanted to do was go through this process in the next 3+ years (hopefully ever). We took a particular care building a strong technology stack. Stay tuned for more technical posts but the main idea is that we now have a separate Ruby API and a Ember web client. It will allow for a lot more flexibility in the future. E.g. opening the API to our users, native mobile apps, etc. It’s documented, tested and fun to work in… All of which are important when scaling a tech team, product and company. This is an investment in the future with returns that will hopefully compound in the future.
If you do not tackle technical debt as you go, it will backfire. And since Visible 1.0 was built as an MVP, always evolving and changing in different directions, had a lot of it. We estimated that if we rewrote the code base, with a strong attention on limiting the code debt, we would be at least twice as productive within 12 months. It is impressive what a good technology stack can do to morale and productivity! Rewrite 2 – Reuse 2
Innovate, don’t duplicate.
We didn’t duplicate the old Visible and just change out the engine. We rethought Visible from the ground up based on all of the feedback from current users, potential ones and where we see the product going. It means that Visible is now at least twice the product it once was, it has an entirely new interface and we doubled down on functionality of our most used features. A good part of the past 6 months was actually spent on changing the core architecture; for instance to allow metrics for quarterly (or any frequency) metrics! You can read about the new features in our release article. Rewrite 3 – Reuse 2
Conclusion
Looking back, it was the right decision to rewrite Visible. It took a lot longer than we first estimated, it was a lot more work and stress than we expected but we pulled it off as a team. We got a lot of great feedback, both positive and negative and are already back at work to improve the product and fix the bugs. And the good news is that you will no longer have to wait month before getting them.
