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?

  • tarwn@alien.topBEnglish
    1·
    10 months ago

    The word quality has different meanings to different people in different contexts. In my experience, a lot of these conversations are oversimplified to the point of uselessness. I can build something that doesn’t work infinitely fast.

    There’s two sides of quality: what the customer experiences (how well are we testing our idea against customers) and what the internal folks experience when they try to add or change what we already built (how fast can we iterate). You can define what matters, or you can tell everyone to “go fast and not worry about quality” and let them each decide what trade-offs to make independently.