Oskar Szulc | product engineering

Question:

with a rewrite we could plan our app structure, backend communication, etc a lot better and create a super performant, high-UX app

Answer:

I saw a fair share of rewrites and I definitely get the appeal of starting fresh. It’s tempting to think that a perfect structure can be invented up front and it will solve product’s issues. Here’s what I think at this stage of my engineering journey:

• Our day to day work is about dealing with complexity and changing requirements. The most performant, future proof and resilient structure on its day 1 will need to eventually change, evolve and grow in unexpected directions. It’s inevitable that it will get bloated or complicated in ways that were hard to predict during the design phase.
• The best way to tackle this I found so far is striving for simplicity and straightforward solutions. The code should meet these requirements IMHO:
  • be easy to remove and extend
  • allow to iterate quickly with high confidence
  • support iterative process
• Thinking about code with functional mindset helps a lot for me. Everything is a step in data processing pipeline – we work with inputs and outputs.
• Exception: UI code is a complexity dead end where we are allowed to do the complex thing that gets us over the finish line. It’s the most disposable part of the app.
• What’s important for me: I think the simplicity of a codebase and its concepts allows to work on emerging “big” issues and produce quick prototypes or proof of concepts for solutions to these problems
• Simple, shallow abstractions between frontend and backend allow us to decide that, for example, we’re going to start server rendering selected parts as a proof of concept and the rest of the app doesn’t need to adjust for that – I think this is a strength.

To wrap up and come back to rewrite:

• With a setup that’s simple enough, a team can do partial rewrites on, let’s say, bi-yearly basis for selected portions of the app. I think this is the cadence that is reasonable in a fast paced startup it emerges on its own by product and customer driven demand.
• A team needs to stay vigilant and maintain a critical mindset. We don’t want to wake up as a technically irrelevant tech company in 3 years. But IMHO this consists of iterative improvement steps rather than starting from scratch every year.
• There are techniques that help to roll out improvements in parallel to existing deployment.
• Abstract example: we can create GraphQL endpoint for certain domain in our app and make one feature use it alongside existing REST API.
• To some extent, wanting to rm- rf on existing code is inherent engineer’s mood – we just need to know how to gradually address this so that we serve both product and customers needs alongside of making sure that developers have good time working with the code.
• I believe it’s good to know the data when assessing “rewrites”. What are we trying to improve? Which metric will move and by what factor? We don’t do great job in this department right now. with this in mind it’ll be much easier to spend a week every couple months on prototyping a new approach and judging the impact.