Often CTOs and Tech leads praise the importance of code quality and the necessity to use cutting edge frameworks.
Having worked for several startups and a VC company I however saw an anti-correlation between the code quality and the company's success.
What are your experiences?
It depends - I don't think there is an true answer to this question.
I've worked both in early stage startups and in companies that are established and are still using their original startup code base. I've seen some terrible design decisions coupled with quality code that survived 15 years because the company had amazing market fit. It cost the developers a lot of extra time to work around the poor design decision, but the company was profitable enough to make up for the dev cost. That's the most common situation I've seen.
The best codebase I've ever worked with was beautiful because the company had long lead time on sales(avg deal took 12 months) so the developers had time to refactor as needed. This company is still alive, so I consider them a success!
The other factor in code quality + business success is team size. With a big team and poor quality code, it spirals down much faster, each new bug/feature gets harder and slower to implement. If its bad code but its always the same 2 developers, they will be consistent enough in their own styles that the code base will not degrade nearly as fast.
I completely agree. A thriving business with a poor quality codebase is the problem you want to have. Use the cash generated by business to pay developers to carefully refactor the offending parts of the codebase or architecture in a direction that reduces the specific business problems being caused by the poor code. Situation is not only sustainable but can be improved.
A business that is not thriving and running out of cash, with a high-quality codebase, is heading toward a terminal failure state. Situation is not sustainable with restricted options and time to recover.
> The other factor in code quality + business success is team size. With a big team and poor quality code, it spirals down much faster, each new bug/feature gets harder and slower to implement.
Slightly generalised, this a good rule of thumb for categorising different kinds of poor code and prioritising remediation efforts. Poor code that is stable that doesn't need to be modified and rarely needs to be read and understood by humans -- it's fine, no business impact, don't touch it. Poor code that causes production outages every week or that multiplies the time and cost of each new feature -- is causing an ongoing cost to business, can estimate business case of value in fixing it, worth prioritising for fix. Per your example, if the bad design is some architectural decision that impacts many developers or many teams each time any team makes a change: increased blast radius, proportionally larger drag on business.
Product Market Fit dictates a startup's success. The code quality or the latest tech frameworks are not the key aspects. I know of companies with low-code / no-code approaches who have made it big.
You like the food from a particular restaurant. Does it really matter to you as a customer, if the chefs were home trained or went to a culinary institute, whether they wing it or follow detailed standardized recipes?
I worked for startups since 6 years ago and even though each was slightly different all had one thing in common - the most important thing was to serve the customer. The only thing we could do was to try to keep everything as flat and as decoupled as possible so we can refactor when time allows (which, by the way, was very rare). I used to think working for startups means to make informed decisions between quality and time to market resulting in finding some mysterious sweet spot - I am yet to find one..
I reckon that all things equal, bad code quality in itself does not increase the chances of success.
Bad code quality may be a symptom of rapid iterations and not burning too much cash on development prior to achieving product-market fit. Ability to rapidly iterate and having enough cash to continue operating would both increase chance of success.
On another hand, it could be possible to have glacially slow iterations while burning truckloads of cash and still have low quality code. E.g. hiring an unnecessarily large team of high-priced developers who are not competent, or trying to operate in the context of some existing complex legacy environment that impedes rapid iterations and delays feedback signals.
I've worked both in early stage startups and in companies that are established and are still using their original startup code base. I've seen some terrible design decisions coupled with quality code that survived 15 years because the company had amazing market fit. It cost the developers a lot of extra time to work around the poor design decision, but the company was profitable enough to make up for the dev cost. That's the most common situation I've seen. The best codebase I've ever worked with was beautiful because the company had long lead time on sales(avg deal took 12 months) so the developers had time to refactor as needed. This company is still alive, so I consider them a success!
The other factor in code quality + business success is team size. With a big team and poor quality code, it spirals down much faster, each new bug/feature gets harder and slower to implement. If its bad code but its always the same 2 developers, they will be consistent enough in their own styles that the code base will not degrade nearly as fast.