Should startups disregard code quality so that they can test their product-market fit as quickly as possible? Or should they write high quality code from the get-go? I used to think the former, but an interesting conversation with Kurt Biesemans made me change my mind. Although there is still room for exceptions, depending on the context. Let’s explore this more deeply.
Finding Product-market Fit
The first thought that comes to mind when talking about technical debt and startups is that they shouldn’t bother about it too much. They should focus on product-market fit, i.e. get a minimal product out there as fast as possible to see if people will buy it.
This idea of a minimal viable product (MVP) was popularized by the Agile movement. The idea is to gather feedback as fast as possible so that you can change your plan and your product until you have something that will sell. Spending too much time building the perfect thing is a waste of money.
After you’ve found something that sells, you can invest time and money in (re)building the application so that it is maintainable and scalable. If necessary, a second round of funding can serve this purpose, but that can mean selling shares of your own company.
Finding Product-market Fit Even Faster
But writing software is expensive. Developers are expensive and it takes time. So what if we could gather feedback faster, cheaper and more easily?
Before you even write the first line of code, you can interview your potential customers and ask them if they have the problems you’re trying to solve. Ask them if they’re happy with how they’re solving these problems right now. Show them mockups of something you’re building or want to build. Use the feedback to change your potential solution and your mockups. Continue this loop to perfect your potential solution.
If you have any uncertainties about a technical solution, build a proof-of-concept. But stick to the original meaning of the word “proof-of-concept”: it should prove a concept and take away any uncertainties or answer questions you have. Throw it away afterwards.
Start Coding
When you’ve designed a concept of a product, you’re ready to start writing the code. And now that you have a better idea of what the market wants and needs, you can pay attention to the quality of the code from the start.
Paying attention to code quality means you’ll be able to keep a sustainable pace of development. You don’t want to be in a position where you need to start scaling your product but you just can’t because the code is a mess.
The above image is by Martin Fowler and shows how industry experts (which he is) experience low quality code. While you can initially deliver faster, this advantage disappears after several weeks (not months).
I would add to that graph that the blue line is more scalable than the brown one. You don’t need the scalability in the early stages of your development, because as a startup you don’t have thousands of customers yet. But once you do reach that point where your architecture needs to support thousands of users, a product with low internal quality will prevent you from doing so.
Evolve
Even though you might have tested your product-market fit with mockups and other low-barrier techniques, your product will still evolve once you have real users. And then you want good quality code. It will allow you to evolve and adapt faster, which is necessary in your startup phase.
But technical debt is unavoidable. So you should have a strategy to deal with it. Kurt Biesemans is a product management consultant who often recommends teams allocate 10% of their sprint to paying back technical debt (and 5% for urgent bugs). Not only does this keep developers happy, it also means you can sustain the current development pace in the long run.
When I talked with Kurt, he mentioned a startup that needed to scale to continue to grow their business, but just couldn’t because of technical debt.
It Depends
As always in software development (and life!), the above all depends on your context. If you’re building something that will have a limited lifetime, you can take shortcuts and accumulate some technical debt. If the code is going to be thrown away in the short term, taking on technical debt could be a valid strategic decision.
Is It Too Late?
What if you’re reading this and realize you’ve not been paying attention to the quality of your code and your architecture? What if you foresee a need to scale or modify your application substantially in the future? Or what if you don’t even know the current state of your code?
It’s never too late to turn things around. I can help with a code assessment or we could schedule a call where you ask me anything. I’m convinced your project can be fixed so that it can scale in the near future and that the pace of development can be sustained in the long run!