Clean coders dilemma

Trade off between code quality and feature development

Last weekend, while listening to The Innovator’s Dilemma, the classic book on the nature of technological disruption, I was thinking about its parallels with writing clean code. The core idea of the book is that established companies focus too much on the needs of the current customers and may miss out on disruptive new technology. Startups on the other hand do not have that ‘baggage’ and can disrupt the incumbent’s business with innovation. The dilemma then is for a company to balance the need of current customers with the need to innovate. 

Surprisingly, I experienced a similar dilemma while struggling to prioritize cleaning up an existing code base and delivering direct end-user value with feature development. Focusing on current customer needs seems to be the right thing to do, but it comes with the cost of slower feature development over the long term because of poor code quality. Besides, it is even hard to convince the product management of the value, given the incentives are to deliver end-user value faster. Ultimately, a lot of projects are ‘disrupted’ by new initiatives to rewrite the code base or by a SAAS offering. Both of the alternatives are expensive. 

Writing good code is easier in the earlier stages of the project, just as innovating is easier for a startup. 

Interstingly, innovating and writing quality code both get progressively difficult over time. Since the code after a while solves existing use-cases, it is hard to remove/refactor a bad interface and improve the code structure. Just like an established company has a ‘baggage’ of existing users, code has the ‘baggage’ of existing code, features, and use cases. 

Prioritizing between refactoring and feature development is hard. One thing we can all do is keep the campground clean, i.e. leave the codebase in a better state than it was found.