Navigating the Balance of Code Quality and Project Success

Quick Takeaways

• High-quality code is mainly about keeping good iteration speed over time - can you add features without breaking what works?
• Not all code needs to be high quality - focus your efforts on the code that's most important, changes often, or creates the most value.
• The right time to refactor is after you know your product has value, but before technical debt gets too big - make small improvements bit by bit.
• Architecture decisions need more thought than other code quality factors since they're hardest to change later - ask "how hard would this be to remove?"
• Balance between MVP and quality depends on your situation - for experiments, cut corners on purpose; for critical systems or enterprise products, focus on quality from the start.

Introduction

In the first episode of No Silver Bullet live podcast, we talk about the balance between writing high-quality code and taking shortcuts.

Based on nearly 20 years of working together on various projects, we discuss when it makes sense to move fast rather than aim for perfect code, and how to avoid technical debt that can kill your project.

We focus on making mindful engineering decisions instead of blindly following rules like "always do X" or "never do Y".Different situations need different approaches to code quality.

Notes

• "No Silver Bullet": The classic 1986 paper by Fred Brooks that our podcast name references, discussing how there's no single development that will solve all software engineering challenges.
• Our Learning Platform: /learn: The project we discussed that started as an MVP and was later refactored
• Architecture Patterns:
• Pareto Principle: The 80/20 rule we mentioned - often 20% of the code creates 80% of the value
• Future Episodes:
• Development Practices:

Quotes

Quality is not about some kind of elegance of code because it's just an artificial thing. It's not really helpful for your team if it's pretty. - Miłosz

Often you have in the code places that you don't touch often or it's not earning a lot of money... Ask what are the places that we're changing the most often? What are the places that are creating most of the value? - Robert

I remember one project when we started applying Domain-Driven Design... Everyone loved it in the team... But what I also remember is that it had no paying users and we had to shut it down. - Miłosz

If you did your dirty POC, don't miss the time when you should clean it up, because it's easy to go into a spot where it's no longer possible to do that. - Robert

After working with [legacy systems] for long enough, you might think, 'I've had enough of this, I won't allow my next project to rot like this one.' It sounds like a good idea, but it can also be a trap. - Miłosz

Sometimes it can be even the opposite. Having everything super consistent can actually be worse than having inconsistent things, because keeping this consistency requires effort... Sometimes it requires you to use an approach that is not optimal just because 'we're doing it consistently.' - Robert

A useful mental model here is to care about the useful product first, not the technical design, which of course is important, but I think it's easy to overvalue it. - Miłosz

Try to find some places where you can do refactoring in one week... Often you don't need to rewrite an entire service. You can just do some refactoring in the code and iterate on that. - Robert

Episode notes and summary: https://threedots.tech/episode/when-to-write-low-quality-code/