A few weeks ago, a young startup engineer reached out to me for advice. Her CEO had given her team 4 weeks to rewrite the web product from scratch. That was over 3 months ago. The project was now 2 months behind, the team was working overtime at 80+ hours per week, and a laundry list of bugs remained. Stress levels were high, and each passing day of not shipping meant that business opportunities at their fledgling startup might fall through. What should she do?
Being caught in the middle of a rewrite project that’s behind schedule sucks. There’s no ignoring it. I’ve been there myself, earlier in my career. One rewrite project I worked on was originally scheduled for 4 months but didn’t ship until after 9 months. Another lasted for 9 months until it was ultimately abandoned. Extremely talented engineers worked grueling hours both times, and some even burned out. One of the worst parts about long rewrites is that when a critical new market opportunity comes up that requires building on top of the code being rewritten, you have to make a difficult choice: do you defer (and possibly lose) the opportunity by building on top of the new codebase and waiting for the new codebase to ship, or do you build it on top of the old codebase and then rewrite it a second time in the new? Neither choice is that appealing.