Avoid re-architecting
“Companies often fail before the code does”
Here are the three steps that lead to the decision to suddenly stop everything and re-architect the product.
Step 1 - Shaming the past team
The new consultant (or new CTO or new product head} sighs and looks you strait in the eye and says: “Quite frankly, this product is really fucked up and needs to be re-architected … because those last folks really did not know what they were doing …and that is why you have trouble shipping new features”.
Step 2 - Promising you what you thought you already had
“Once we rebuild this thing the right way, we will be able to start adding the features you want incredibly fast!”
Step 3 - Pressing the hot buttons
If we don’t stop and rearchitect now, we will not scale to beyond X million users.
If we don’t stop and re-architect now, we will not pass due-diligence when we get acquired/funded.
If we don’t stop and rearchitect now, we will not be able to get developers to work on the product.
Have, you heard these before? The conversation can make you scared and mad at the same time; especially if you remember that the previous team said exactly the same thing when they took over.
THE LIKEY OUTCOME
You decided to go with the team’s recommendation and re-architect the product. It is now one year later and anticipation is high. For months now it seems all anyone has been talking about internally is the new architecture. Sales is at the end of their ropes waiting for the new features next on the priority list and CX has sold the benefits to the client base and has been holding them at bay for months. But the launch turns out to be the worst you have ever shipped. Feature parity is severely lacking. Important edge cases are no longer supported and customers that never had problems before are now having problems. Instead of being a product-oriented company pumping out features, your organization is now going to spend another year battling to get back to where you were a year ago. To top it all off, in another six months, members of your product team will start whispering that the (new) architecture was not done right.
THE TRUTH
Real engineering is a balance of compromises; decisions made with the current constraints in view. Products bear the scars of those past choices (often good ones). But given time and the natural turnover in teams, the memory around these choices fades. Your team might tell you the production code is a mess. Trust me, real production code is always “a mess” because it has been battle hardened in the field and now supports multiple, nuanced corner cases.
To be clear, there are legit technical and business reasons to rearchitect a product; too many to go into here. However, a new team’s emphatic need to dismiss legacy code is usually not one of them. Ask yourself if up-time or deployments have been a real issue. Ask yourself if your customers are directly suffering due to your current architecture. The code that is in production and making you money is more valuable than the code that has not been written yet. So, don’t throw it away without a fight. Focus is everything. Companies often fail before the code does.
