Hacker News Reader

Comment by mojuba | Hacker News Reader

> 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.

View on HN

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.

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'.

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?"

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.

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.

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.

It's very unlikely the bugs killed those startups.

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.

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

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.

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.

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

Examples?

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

>>> 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

That’s pretty much my point...

i misunderstood your point - it is a bit clearer on a reread

For a long time Pandora was much better written than Spotify. Pandora was stable and performant and Spotify always slowed down my phone and would crash it consistently sometimes in way that required a phone restart.

Spotify won because they had a large selection of music which was more important than the occasional frustrations.

Windows 3.0 was very successful, but it crashed a lot.

Twitter used to crash all the time.

Edit: from 'Twitter?' to the above.

Early Android.

Do you remember Facebook Chat when it first came out? Barely worked. People still used it all the time.

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.

> 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.

>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.

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.

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.

> 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 believe that the curves are different. In the short term, just-do-it coding absolutely moves faster. Sustainable practices cost noticeably more visible effort per unit of value created. However the cost of rework eventually catches up with just-do-it and the net value-per-time drops below sustainable practice.

I've seen different anecdotal statements of when those lines cross. I see it as happening within a few weeks, I've heard others say 3-4, some say months, up to 1 or 2 years; I expect these variations are due to many factors. In the most recent codebase where I deliberately prototyped without careful practices became bogged down in about 2 weeks.

While I do agree with the higher-level discussion that software quality is not the only factor affecting market success, I don't believe that it is always advantageous to sacrifice quality on the theory that it will be faster. Success takes longer than most people expect. Setting up a dichotomy between success-needs-quality and success-needs-speed just leads to a kind of stalemate where artillery barrages of anecdotes are exchanged from entrenched opinions.

I was talking about the quality of the product, not the code. Sorry if that was not clear. You need to keep your code clean and simple, that is for sure. But this doesn't mean there will be no bugs in there.

So you can still move fast, have clean code, and end up with some nasty bugs.

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.

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.

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...

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

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.

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.

Reply on news.ycombinator.com