What should be done in a company that's basically committed every error you could commit? What's an engineer to do? Just switch jobs?
I joined a company a few years ago that had hit a wall with its tech stack after 8 years. They brought in a new technical lead who convinced everyone to approve a "rewrite everything from scratch on new stack" approach (even though it rarely works).
2 Years and $40-50m later:
- The thing's nowhere near done. Customers all still using old legacy product that's not been updated in 2-3 years now since resources were diverted to rewrite
- 88% of the eng org has turned over
- current eng org doesn't know how 20-40% of the codebase works
- customers have caught on and started leaving en masse
- Rest of company has turned over as well as they realized nothing useful was going to come out of engineering for years more if ever
It's a bit confusing. What the heck should we do at this point?
I take some solace in knowing that I've seen firsthand what NOT to do in situations like this.
> What should be done in a company that's basically committed every error you could commit? What's an engineer to do? Just switch jobs?
Sometimes that's all you have the power to do. Why are customers leaving en masse if the old product is still functioning?
It sounds like the rewrite got stuck in the pattern where it has to do 100% of the original and then some. Just like a new product, a rewrite has to hit that MVP mark, just not as urgently. They also have to be able to throw out the cruft and not import every bad idea from v1.
Maybe competitors are providing a better product, so customers leave? It's hard to make a new version of a product that does less. Features were presumably mostly added for a reason, and customers probably use them. Removing them is a hard sell.
If there are better alternatives then sticking with the current technical debt may be a non-option as well.
>Features were presumably mostly added for a reason, and customers probably use them. Removing them is a hard sell.
Trying to make everyone happy is one of the big drivers of technical debt, a lot of stuff that gets added just to get that one critical contract. Sometimes you can refactor to better handle these variations that weren't anticipated, but sometimes you can't and you have to evaluate the complications versus that one customers business.
You say this most often in businesses that practice sales team driven development.
Heh I worked at a company that did something like that.
Tell the people above the tech lead, politely, that the failure is a predictable consequence of the decision to rewrite from scratch, and that what they need to do is abandon the rewrite and pour resources into the "legacy" version to fix it. And be prepared to switch jobs. Not necessarily in that order.
What should be done in a company that's basically committed every error you could commit? What's an engineer to do? Just switch jobs?
I joined a company a few years ago that had hit a wall with its tech stack after 8 years. They brought in a new technical lead who convinced everyone to approve a "rewrite everything from scratch on new stack" approach (even though it rarely works).
2 Years and $40-50m later:
- The thing's nowhere near done. Customers all still using old legacy product that's not been updated in 2-3 years now since resources were diverted to rewrite
- 88% of the eng org has turned over
- current eng org doesn't know how 20-40% of the codebase works
- customers have caught on and started leaving en masse
- Rest of company has turned over as well as they realized nothing useful was going to come out of engineering for years more if ever
It's a bit confusing. What the heck should we do at this point?
I take some solace in knowing that I've seen firsthand what NOT to do in situations like this.