Loading...

Investigating the Need For Rewriting a Code Base and Then Successfully Doing So

Alexandra Sobhani

Engineering Manager at Google

Loading...

Problem

I began to notice the frustrated body language of my new hires who later told me that the tickets they were working on were unnecessarily difficult. In any other code base, this would be easy, but our codebase was very tangled. It was essentially a scavenger hunt (bordering on wild goose chase) which was resulting in a lot of wasted time. This was a code base we had inherited where components were all over the place, and although knowing we would have to make some tweaks, I didn't realize a rework was the answer. Another problem was that my manager was very resistant to a rewrite because he had seen rewrites take 3x or 4x the time allotted and the original problems persist.

Actions taken

Investigation

  • A new engineer was persistent with me about the need for a rewrite, but I thought maybe he was too presumptuous or starry-eyed to make that declaration.
  • I decided to speak with my other senior engineer to find out more information. He disclosed that we would have to do some sort of rewrite in the next year because the application was already hitting the limits of its scalability and morale would lower significantly if we didn't.
  • I asked him to tell me more precisely how much dev time percentage wise we were losing due to this code base. I expected him to say maybe 20% because the code base was difficult to navigate but he was clear that it was taking >70% more time to complete tickets due to over engineered, entwined, and unreadable code.
  • We considered an inplace refactor (eg taking each piece of the app separately and rewriting/refactoring it). That way feature work and releases could continue, but when we estimated those timelines each individual piece would take at least twice as long because the app components were so intertwined. We'd be refactoring for years while doing feature work.
  • They estimated a rewrite would take 2-4 months and I calculated that meant in under 10 months we'd have the new version just as far along as the old version (the old version taking 1.7x the time per feature added) Implementation
  • My manager was still hesitant even with my timelines making up my mind. I set to work incrementally convincing him it'd be okay. When he was starting to be less resistant I pushed forward proofs of concept that became larger and larger. The next time he checked in I had solidified with product to make a roadmap/timeline that included a rewrite that I knew would benefit us hugely over the long term.
  • What we ended up doing was have the lead engineer start working on the refactor for the first two months to get the data pipeline and foundational things in line. During this time, the others worked on features in the old code base that we could release to our clients.
  • After roughly two months everyone else joined the rewrite, each person took own their own task responsibilities and got to work on them.
  • In my manager's defense it did take 6 months to complete instead of the estimated 4 months. Though, in those months we did implement new features for the new codebase debut release to clients.

Lessons learned

  • When a decision is right for your engineering team, even if it triggers bad memories in your product/ executives, you may have to take action to push an agenda you believe in.
  • I also learned about the need for padding timelines; I added no padding to the engineering estimates which resulted in a lot of pressure from executives when we slipped. Though our slippage was not nearly what my manager feared.
  • Our product wishlists are churning much faster and our employees are much happier.
  • One of my engineers said of a feature he built in old and new codebase that in the old it took him a month. He then made the same functionality in the new code base and it took seven hours.
  • Hiring new people really helped move this process along quickly.
  • The break up of responsibility was especially good for our juniors to take the second half of the tickets in order to learn things, but also be productive at the same time.

Be notified about next articles from Alexandra Sobhani

Alexandra Sobhani

Engineering Manager at Google


Engineering LeadershipLeadership DevelopmentCommunicationOrganizational StrategyDecision MakingCulture DevelopmentEngineering ManagementPerformance MetricsMentorship Programs

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


Product

HomeCircles1-on-1 MentorshipBountiesBecome a mentor

© 2024 Plato. All rights reserved

LoginSign up