10 ms·

> Which subset of your target customers are so constrained by the status quo, they’ll welcome a buggy product? I understand this is just a mental test, but rea

by mojuba 7y ago

> Which subset of your target customers are so constrained by the status quo, they’ll welcome a buggy product? I understand this is just a mental test, but really... don't release buggy products. Don't create buggy products. Firstly, the line between forgivable bugs and unforgivable ones is too thin. Or sometimes N forgivable bugs become one big unforgivable show stopper. Second, you will always have a competitor with more experienced engineers and a better choice of tools that they'll beat you at least at quality if nothing else.

BoorishBears 7y ago
If I had a dollar for every business that was killed by a buggier competitor, I bet I’d have a lot more dollars than if I got one for every time a business was killed by bugs. People will put up with a lot of nonsense for a product that does what they want.
- AmericanChopper 7y ago
  I dunno, I’ve seen plenty of startups killed by the mentality that calling their shitty product an ‘MVP’ somehow makes up for how shitty it is.
  - randomsearch 7y ago
    It's very unlikely the bugs killed those startups.
    - AmericanChopper 7y ago
      Depends on how you classify bugs. If a bug is anytime your product doesn’t work the way it’s supposed to, then yeah, I’ve seen startups suffer massively from that. I worked with one that had 90% of new customers churn out in their first month (you might be able to guess, that company doesn’t exist any more). If you broaden your definition to include ‘problems with the code base that significantly slow down new features’, then I’ve seen even more startups die trying to release their ‘v2.0’. The thing about the ‘we’ll iterate on it later’ mentality is that your product has to be in pretty good shape to be able to benefit from small incremental improvements. If it’s a garbage fire then making the smallest changes turns into an arduous nightmare, that inevitably just ends up introducing even more bugs to your product. But to be fair, for as many startups as I’ve seen go out of business due to these problems, I’ve seen just as many stagnate into a state where they have just enough revenue to cover their small payroll, and remain in that state for a very long time.
      - BoorishBears 7y ago
        What if I take bug to mean what it means? > A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. 90% churn out rate is not a software bug... If you mean there was a software bug that was causing that, it sounds like they had a bug that was completely preventing them from providing value. It’s a given your product needs to be able to provide some sort of value. My point is people place much more emphasis on provided value and utility over frustration from bugs
        AmericanChopper 7y ago
        But even if the app crashes every time it loads, that would meet your definition of a bug. I’ve never personally seen a single bug so bad that it killed a company, but I’ve seen products so riddled with bugs that they killed companies. An app with chronic stability issues? Those are bugs. Automated processes silently fail some times? Bugs. Interactive processes randomly fail sometimes? Bugs. I’ve seen plenty of companies with ideas that seemed decent fail because they were unable to deliver an adequately functional product, for the sort of reasons I mentioned above. All of which I’d consider bugs.
        BoorishBears 7y ago
        I already addressed an app crashing every time it loads in another comment. My point wasn’t you can deliver an app that does nothing and succeed. My point was bugginess is not what kills most start ups. Lack of bugginess is not a moat. Your competitors will not automatically fail because your app is the most stable one.
  - BoorishBears 7y ago
    There'll always be examples to the contrary, but usually that’s a problem of not providing enough value. Think about how much crappy software there is out there that people use because it does something they need. If “not having bugs” is literally your only moat, there were always bigger problems
    - dustinmr 7y ago
      Examples?
      - BoorishBears 7y ago
        I mean, take it to it’s logical extreme, I make an app that does X, but every time you start it, it crashes. I doubt it’s going to be long before my product fails, bugs are affecting the value users derive from it to an extreme degree, past what they can overlook. I honestly can’t even think of a real-world example off the top of my head though. But that’s probably just a testament to how badly you need to screw up for bugs to be the actual reason a product fails, and not some external factor that’s possibly exacerbated by bugginess
        lifeisstillgood 7y ago
        >>> I make an app that does X, but every time you start it, it crashes. Then it doesn't do X Buggy code is a huge drag on any codebase and any business built on that codebase - absolutely. But if you list all the things you think you MUST fix in a codebase, they are all things that make you as a developers life harder. The bugs that a user sees are the ones that take away the value they get - the ones you see are the ones that make it harder as a developer to work on the code base - they are rarely the same bugs this is the cause of most tension
        BoorishBears 7y ago
        That’s pretty much my point...
xmprt 7y ago
You know what's worse than a buggy product? No product. It's better to launch with a few bugs that you can fix and iterate on the final product design than making the perfect product that no one wants. Also, the question could be reworded to refer to not just bugs but also features since a startup will often pivot in some way even after launching which users will have to deal with.
jasonwen 7y ago
If the pain point you are solving is big enough, people will accept buggy and slow products regardless. Sometimes its better to ship, especially if you are testing product market fit. A bug free, slick, with awesome tech used, is worth nothing if no one is willing to pay for it/solves a big enough problem.
krsrhe 7y ago
Maybe if you are building rocket ships. But even SpaceX is doing pretty well with rockets that explode sometimes.
- mojuba 7y ago
  Because when you build a rocket there are a lot of unknowns for you that you'd be discovering and testing in the field. With software the only unknown is usually the market fit. There are rarely any unknowns in the implementation and there is no reason not to test your software before you release it to the public.
  - mobjack 7y ago
    Bugs get missed in testing because developers can't anticipate all the ways users can break it. That is why beta testing exists. There are also bugs that are rare and take lots of effort to fix. You can first see how often that bug actually occurs in the wild before prioritizing it. Sometimes it never occurs or if it does happen, the user can recover from it easily so it doesn't break your product.
deleted 7y ago
[deleted]
koonsolo 7y ago
> Second, you will always have a competitor with more experienced engineers and a better choice of tools that they'll beat you at least at quality if nothing else. Software development is always about trade-offs. You can churn out way more features if you don't need to take quality into account. I would welcome any competitor in my field who is super focused on quality, since they will waste a lot of time and money that could better be spent elsewhere. For example, I'm not going to make some code bug-free, when there is a 50% chance that that feature will end up in the wastebasket 2 months later. Besides, you talk about unforgivable bugs, but what are they to your early adopters anyway? I had users lose half a day of work because the save crashed right in the middle of it. They weren't even angry. They said is was inconvenient and just remade the whole thing. When I fixed it they were happy. They are still users now. That's how "unforgivable" these are to early adopters. So yeah, don't forget one of the bigger companies had a "Move fast and break things" policy. In the end it's the market that decides. And according to my experience, early adopters are super forgiving.
- mojuba 7y ago
  >You can churn out way more features if you don't need to take quality into account. Creating quality code should not be at the expense of extra features. Just hire more competent, experienced engineers and there will be no need to sacrifice one for the other. Quality is a function of experience and skill, it is not (or should not be) a function of development time.
  - mobjack 7y ago
    There are still tradeoffs to be made no matter your skill level. Good engineers choose between the minimal acceptable quality vs high quality code. Bad engineers struggle to get create minimal acceptable quality in the first place.
  - koonsolo 7y ago
    I was talking about bug quality, not code quality. Sorry if that was not clear. And as any competent, experienced engineer knows, those two are less related than a junior would think. I agree you have to keep your code clean. But the absence of bugs is an entirely different thing.
vincentmarle 7y ago
I’ve heard this complaint before (and it’s usually from junior engineers who don’t have much experience). Here’s my take: I worked on a project that arguably had the worst code I’ve ever worked on but still made $100 million dollars in annual revenue. And then I worked on an app with terrible UX that became a billion dollar company. In both cases we had terrible reviews and a huge customer support team to process thousands of complaints, but it worked for the majority of the millions of users. And then I realized that terrible design and bugs don’t really matter if you have true product market fit. And vice versa you can have the best design and flawless error logs but still fail if you’re not creating something that people want, especially if it takes you extra time and resources to create that “perfect product” while your competitors bypass you with a shittier product, but with faster iterations.
sah2ed 7y ago
I think the mental test could have been framed better using the IMHO far more intuitive framing used by Don Dodge in his 2008 article about how to assess a fresh batch of YC startups. Is your product a vitamin (nice to have) or a pain killer (a must have to improve quality of life)? https://dondodge.typepad.com/the_next_big_thing/2008/03/does-your-start.html https://dondodge.typepad.com/the_next_big_thing/2008/03/does...
carapace 7y ago
I hate it but you're wrong. (I agree with you, but I'm wrong too.) I used to work for a small company that made it big (you've heard of them.) We went from ~25k to ~250k users while I was there and the VCs were lining up to pound money up the founders' asses. Limosine rides and $500 steak dinners to woo them, the whole thing. I left, they eventually went public, and last I heard the Walton family owns it now or something. Anyway... The front-end guy "Chris" (not his real name) and the back-end guy were pals, and they would just push any old shit to production. The CEO had no clue, and I wasn't in a position to get them to stop. There was one other guy working remotely who didn't care or also had no clue. So, "Chris" (not his real name) would shit out some PHP, bang on the new feature or whatever for a few seconds, and if it worked even slightly at all he would push it. Shit broke all the time. The poor dumb users would be on the support forums telling each other how the heroic Chris was working furiously to fix it, and I'm sitting there fuming because Chris is the ruthless asshole using them as unpaid QA. That fucker is a millionaire now. Go figure.
- sonnyblarney 7y ago
  This is a very good anecdote, and helps us understand that 'shit' is in the eye of the beholder. If it solves a real problem, and allows companies to do 'xyz' , maybe it doesn't matter if there are bugs and glitches here and there. If there is only 'one kind of car' and that's all anyone knew, nobody would mind that there were always leaky oil issues if the alternative was 'horses'.
  - kyshoc 7y ago
    Indeed. The YC application has a question along the lines of "why is the thing you're building so compelling that customers will tolerate a buggy product?"
  - carapace 7y ago
    It's a terrible anecdote, it's only redeeming quality is that it's based on a true story. We could have fired Chris and replaced him the next day. We should have. We will never be able to know or quantify the loss accrued to Chris's irresponsible behavior. We got lucky. It costs nothing extra to write correct bug-free code if you know how, and bug-free code will always be preferable to buggy code.

by mojuba 7y ago

BoorishBears 7y ago

If I had a dollar for every business that was killed by a buggier competitor, I bet I’d have a lot more dollars than if I got one for every time a business was killed by bugs. People will put up with a lot of nonsense for a product that does what they want.

AmericanChopper 7y ago
I dunno, I’ve seen plenty of startups killed by the mentality that calling their shitty product an ‘MVP’ somehow makes up for how shitty it is.
- randomsearch 7y ago
  It's very unlikely the bugs killed those startups.
  - AmericanChopper 7y ago
    Depends on how you classify bugs. If a bug is anytime your product doesn’t work the way it’s supposed to, then yeah, I’ve seen startups suffer massively from that. I worked with one that had 90% of new customers churn out in their first month (you might be able to guess, that company doesn’t exist any more). If you broaden your definition to include ‘problems with the code base that significantly slow down new features’, then I’ve seen even more startups die trying to release their ‘v2.0’. The thing about the ‘we’ll iterate on it later’ mentality is that your product has to be in pretty good shape to be able to benefit from small incremental improvements. If it’s a garbage fire then making the smallest changes turns into an arduous nightmare, that inevitably just ends up introducing even more bugs to your product. But to be fair, for as many startups as I’ve seen go out of business due to these problems, I’ve seen just as many stagnate into a state where they have just enough revenue to cover their small payroll, and remain in that state for a very long time.
    - BoorishBears 7y ago
      What if I take bug to mean what it means? > A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. 90% churn out rate is not a software bug... If you mean there was a software bug that was causing that, it sounds like they had a bug that was completely preventing them from providing value. It’s a given your product needs to be able to provide some sort of value. My point is people place much more emphasis on provided value and utility over frustration from bugs
      - AmericanChopper 7y ago
        But even if the app crashes every time it loads, that would meet your definition of a bug. I’ve never personally seen a single bug so bad that it killed a company, but I’ve seen products so riddled with bugs that they killed companies. An app with chronic stability issues? Those are bugs. Automated processes silently fail some times? Bugs. Interactive processes randomly fail sometimes? Bugs. I’ve seen plenty of companies with ideas that seemed decent fail because they were unable to deliver an adequately functional product, for the sort of reasons I mentioned above. All of which I’d consider bugs.
        BoorishBears 7y ago
        I already addressed an app crashing every time it loads in another comment. My point wasn’t you can deliver an app that does nothing and succeed. My point was bugginess is not what kills most start ups. Lack of bugginess is not a moat. Your competitors will not automatically fail because your app is the most stable one.
- BoorishBears 7y ago
  There'll always be examples to the contrary, but usually that’s a problem of not providing enough value. Think about how much crappy software there is out there that people use because it does something they need. If “not having bugs” is literally your only moat, there were always bigger problems
  - dustinmr 7y ago
    Examples?
    - BoorishBears 7y ago
      I mean, take it to it’s logical extreme, I make an app that does X, but every time you start it, it crashes. I doubt it’s going to be long before my product fails, bugs are affecting the value users derive from it to an extreme degree, past what they can overlook. I honestly can’t even think of a real-world example off the top of my head though. But that’s probably just a testament to how badly you need to screw up for bugs to be the actual reason a product fails, and not some external factor that’s possibly exacerbated by bugginess
      - lifeisstillgood 7y ago
        >>> I make an app that does X, but every time you start it, it crashes. Then it doesn't do X Buggy code is a huge drag on any codebase and any business built on that codebase - absolutely. But if you list all the things you think you MUST fix in a codebase, they are all things that make you as a developers life harder. The bugs that a user sees are the ones that take away the value they get - the ones you see are the ones that make it harder as a developer to work on the code base - they are rarely the same bugs this is the cause of most tension
        BoorishBears 7y ago
        That’s pretty much my point...

xmprt 7y ago

You know what's worse than a buggy product? No product. It's better to launch with a few bugs that you can fix and iterate on the final product design than making the perfect product that no one wants. Also, the question could be reworded to refer to not just bugs but also features since a startup will often pivot in some way even after launching which users will have to deal with.

jasonwen 7y ago

If the pain point you are solving is big enough, people will accept buggy and slow products regardless. Sometimes its better to ship, especially if you are testing product market fit. A bug free, slick, with awesome tech used, is worth nothing if no one is willing to pay for it/solves a big enough problem.

krsrhe 7y ago

Maybe if you are building rocket ships. But even SpaceX is doing pretty well with rockets that explode sometimes.

mojuba 7y ago
Because when you build a rocket there are a lot of unknowns for you that you'd be discovering and testing in the field. With software the only unknown is usually the market fit. There are rarely any unknowns in the implementation and there is no reason not to test your software before you release it to the public.
- mobjack 7y ago
  Bugs get missed in testing because developers can't anticipate all the ways users can break it. That is why beta testing exists. There are also bugs that are rare and take lots of effort to fix. You can first see how often that bug actually occurs in the wild before prioritizing it. Sometimes it never occurs or if it does happen, the user can recover from it easily so it doesn't break your product.

deleted 7y ago

[deleted]

koonsolo 7y ago

> Second, you will always have a competitor with more experienced engineers and a better choice of tools that they'll beat you at least at quality if nothing else. Software development is always about trade-offs. You can churn out way more features if you don't need to take quality into account. I would welcome any competitor in my field who is super focused on quality, since they will waste a lot of time and money that could better be spent elsewhere. For example, I'm not going to make some code bug-free, when there is a 50% chance that that feature will end up in the wastebasket 2 months later. Besides, you talk about unforgivable bugs, but what are they to your early adopters anyway? I had users lose half a day of work because the save crashed right in the middle of it. They weren't even angry. They said is was inconvenient and just remade the whole thing. When I fixed it they were happy. They are still users now. That's how "unforgivable" these are to early adopters. So yeah, don't forget one of the bigger companies had a "Move fast and break things" policy. In the end it's the market that decides. And according to my experience, early adopters are super forgiving.

mojuba 7y ago
>You can churn out way more features if you don't need to take quality into account. Creating quality code should not be at the expense of extra features. Just hire more competent, experienced engineers and there will be no need to sacrifice one for the other. Quality is a function of experience and skill, it is not (or should not be) a function of development time.
- mobjack 7y ago
  There are still tradeoffs to be made no matter your skill level. Good engineers choose between the minimal acceptable quality vs high quality code. Bad engineers struggle to get create minimal acceptable quality in the first place.
- koonsolo 7y ago
  I was talking about bug quality, not code quality. Sorry if that was not clear. And as any competent, experienced engineer knows, those two are less related than a junior would think. I agree you have to keep your code clean. But the absence of bugs is an entirely different thing.

vincentmarle 7y ago

I’ve heard this complaint before (and it’s usually from junior engineers who don’t have much experience). Here’s my take: I worked on a project that arguably had the worst code I’ve ever worked on but still made $100 million dollars in annual revenue. And then I worked on an app with terrible UX that became a billion dollar company. In both cases we had terrible reviews and a huge customer support team to process thousands of complaints, but it worked for the majority of the millions of users. And then I realized that terrible design and bugs don’t really matter if you have true product market fit. And vice versa you can have the best design and flawless error logs but still fail if you’re not creating something that people want, especially if it takes you extra time and resources to create that “perfect product” while your competitors bypass you with a shittier product, but with faster iterations.

sah2ed 7y ago

I think the mental test could have been framed better using the IMHO far more intuitive framing used by Don Dodge in his 2008 article about how to assess a fresh batch of YC startups. Is your product a vitamin (nice to have) or a pain killer (a must have to improve quality of life)? https://dondodge.typepad.com/the_next_big_thing/2008/03/does-your-start.html https://dondodge.typepad.com/the_next_big_thing/2008/03/does...

carapace 7y ago

I hate it but you're wrong. (I agree with you, but I'm wrong too.) I used to work for a small company that made it big (you've heard of them.) We went from ~25k to ~250k users while I was there and the VCs were lining up to pound money up the founders' asses. Limosine rides and $500 steak dinners to woo them, the whole thing. I left, they eventually went public, and last I heard the Walton family owns it now or something. Anyway... The front-end guy "Chris" (not his real name) and the back-end guy were pals, and they would just push any old shit to production. The CEO had no clue, and I wasn't in a position to get them to stop. There was one other guy working remotely who didn't care or also had no clue. So, "Chris" (not his real name) would shit out some PHP, bang on the new feature or whatever for a few seconds, and if it worked even slightly at all he would push it. Shit broke all the time. The poor dumb users would be on the support forums telling each other how the heroic Chris was working furiously to fix it, and I'm sitting there fuming because Chris is the ruthless asshole using them as unpaid QA. That fucker is a millionaire now. Go figure.

sonnyblarney 7y ago
This is a very good anecdote, and helps us understand that 'shit' is in the eye of the beholder. If it solves a real problem, and allows companies to do 'xyz' , maybe it doesn't matter if there are bugs and glitches here and there. If there is only 'one kind of car' and that's all anyone knew, nobody would mind that there were always leaky oil issues if the alternative was 'horses'.
- kyshoc 7y ago
  Indeed. The YC application has a question along the lines of "why is the thing you're building so compelling that customers will tolerate a buggy product?"
- carapace 7y ago
  It's a terrible anecdote, it's only redeeming quality is that it's based on a true story. We could have fired Chris and replaced him the next day. We should have. We will never be able to know or quantify the loss accrued to Chris's irresponsible behavior. We got lucky. It costs nothing extra to write correct bug-free code if you know how, and bug-free code will always be preferable to buggy code.