While looking over some presentations of new software projects/companies, it was hard to ignore the fact that some of them had missing major functionalities or even worse, the investors were pointing out some showstopper bugs. I’m talking about new companies, young ones, that probably got already a round of investment.
Other thing I noticed was that some companies, after 6 to 12 months after their initial investment, end up drowning in bugs and refactorings which are causing dev work to hinder and not develop new features as planned. Those missing features are often the reason of a failed second investment round.
Of course, these are the worse case scenarios and it’s not happening for ALL the startups. It’s not something I wish, it’s just something that I see everyday. All the major sources specify the same kindof news: “About 90% of startups fail. 10% of startups fail within the first year. Across all industries, startup failure rates seem to be close to the same. Failure is most common for startups during years two through five, with 70% falling into this category.”
Identifying this problem, I took the role of the CTO for a testing company. The main goal is to help start-ups building quality work. This is what it matters, because others success is our success. Our role is to bring expertise and fresh perspective to projects, contributing to the overall improvement of software quality within an organization.
So, how important is QA for you, and when do you decide it’s time to invest in it? Have you seen good ideas not getting investment because of bad quality? How is anybody overcoming this?
With a cash strapped startup you do need to deliver version one fast and version two right. If you take the time to it right at the beginning, chances are that you will run out of money before the product is even out.
Worse, you might work your ass off building something polished that will not resonate with the market and generate any sales - so you will have to redo it all anyway. It is very very very very rare that a startup nails the product market fit on the first try.
Yup. Version 1 fast and version 2 right. The problem is that normally feature requests a, b, c, and d come rolling in, and quality updates are postponed to version 3. Then, with a growing customer base, in comes half the alphabet in feature requests, and quality updates are postponed to version 4, 5, or 6.
It’s not easy to balance new features vs paying technical debt. I see building software like buying a house.
Very few young people can wait long enough to buy a house in cash - they need a mortgage.
Very few young companies can afford wait long enough to build perfect software so they need to borrow some technical debt.
Just like your mortgage, you need to pay back technical debt even though you’d like to spend your money (or ressources) elsewhere.