Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Responding to “Are bugs and slow delivery ok?”

uselessdevblog.wordpress.com

Post reply on HN
Print view View original

41–50 of 128 posts

Re: Responding to “Are bugs and slow delivery ok?”

#41

Post by the_gipsy »

PragmaticPulp wrote: post #7

> You know what I haven’t seen? not once in 15 years? > A company going under. What a wild assertion: The OP hasn’t personally seen a company fail, and therefore software quality doesn’t matter? Bugs and slow delivery are fine? It’s trivially easy to find counterexamples of companies failing because their software products were inferior to newcomers who delivered good results, fast development, and more stable experi…

It should have been "going under due to bugs / low quality and slow delivery".

Re: Responding to “Are bugs and slow delivery ok?”

#42

Post by tobr »

fifticon wrote: post #24
PragmaticPulp wrote: post #7

> You know what I haven’t seen? not once in 15 years? > A company going under. What a wild assertion: The OP hasn’t personally seen a company fail, and therefore software quality doesn’t matter? Bugs and slow delivery are fine? It’s trivially easy to find counterexamples of companies failing because their software products were inferior to newcomers who delivered good results, fast development, and more stable experi…

I was in a successful company that nearly died in 2017, where our entire production system corrupted itself due to a sneaking scale bug we had ported the system into. The problem was, the system with data had been running migrated for 3 months with the bug in it, so it was no longer possible to revert to the earlier working design. We were down for a week where no clients could run, and we spent the next 12 months pu…

What I’m hearing here is that even a software problem so bad it forced you to focus on nothing except trying to fix it, for a full year, wasn’t bad enough to make the company go under.

Re: Responding to “Are bugs and slow delivery ok?”

#43

Post by Yoric »

PragmaticPulp wrote: post #7

> You know what I haven’t seen? not once in 15 years? > A company going under. What a wild assertion: The OP hasn’t personally seen a company fail, and therefore software quality doesn’t matter? Bugs and slow delivery are fine? It’s trivially easy to find counterexamples of companies failing because their software products were inferior to newcomers who delivered good results, fast development, and more stable experi…

For what it's worth, Mozilla was nearly killed at least twice by code quality.

Once upon startup. The code inherited from Netscape was... let's say charitably difficult to maintain. Turning it into something that could actually be improved upon and tested took years without any release of the Mozilla Suite.

Once when Chrome emerged. Not because the code was particularly bad, but because its architecture didn't reflect more modern requirements in terms of responsiveness or security. See https://yoric.github.io/post/why-did-mozilla-remove-xul-addo... for a few more details.

Re: Responding to “Are bugs and slow delivery ok?”

#44

Post by drewcoo »

PragmaticPulp wrote: post #7

> You know what I haven’t seen? not once in 15 years? > A company going under. What a wild assertion: The OP hasn’t personally seen a company fail, and therefore software quality doesn’t matter? Bugs and slow delivery are fine? It’s trivially easy to find counterexamples of companies failing because their software products were inferior to newcomers who delivered good results, fast development, and more stable experi…

> It’s trivially easy to find counterexamples of companies failing because their software products were inferior to newcomers who delivered good results, fast development, and more stable experience.

Is it? What I've seen is the opposite.

Businesses can be terrible top to bottom, slow, inefficient, and painful for customers, and still keep going for years and years. It's more about income/funding than product.

> I think the author may have been swept up in big, slow companies that have so much money that they can afford to . . .

That's what I'm talking about. They are legion! They could be companies that serve a niche that no one else does or with prohibitive switching costs (training is expensive). They could also be companies that somehow got enough market share that "no one gets fired for buying IBM."

Also, you know what those "big, slow companies" have in common? They are successful businesses. Unlike most startups.

Re: Responding to “Are bugs and slow delivery ok?”

#45

Post by qingcharles »

commandlinefan wrote: post #21

I've been coding now for about 30 years. I've never moved up into management and, now at almost 50, it's pretty clear I never will, and will spend the remainder of my career coding (which I'm perfectly fine with). In the 30 years I've been coding, languages have come and gone, platforms have come and gone, frameworks have come and gone, methodologies have come and gone, but two things have never changed: 1) Software…

Thank you for (1). I was trying to explain to someone the other day how unpredictable coding is, but you're right, it's wildly unpredictable. Even for tiny projects they sometimes go so far off the rails.

I remember working on this one major project - an online music store - and one of the execs hired his very lovely wife to project manage a team of developers. She would create these fantastic charts in Microsoft Project and every day try to somehow - somehow - get the developers to either (a) give her timescales for each component, or (b) explain why previous component X took twice as long as they had scheduled.

I've been writing code for 40 years and I still get caught out myself. I try to give realistic deadlines and then some fucking bug in the compiler or other such insanity will come along and make me look like a fool.

Re: Responding to “Are bugs and slow delivery ok?”

#46

Post by embwbam »

commandlinefan wrote: post #21

I've been coding now for about 30 years. I've never moved up into management and, now at almost 50, it's pretty clear I never will, and will spend the remainder of my career coding (which I'm perfectly fine with). In the 30 years I've been coding, languages have come and gone, platforms have come and gone, frameworks have come and gone, methodologies have come and gone, but two things have never changed: 1) Software…

In my experience, one can accurately predict development time by correctly working around the planning fallacy.

The planning fallacy is something like "Humans are hopelessly optimistic. Even if you think you're planning for the worst case, unexpected things will happen, and your estimate is more like the best case scenario. This is true even if you try to compensate for the planning fallacy by being more pessimistic".

So you can't fix it by padding more weeks, trying to think of all the things that might happen, etc.

The only way to compensate for this is detailed in Kahneman's "Thinking Fast and Slow" (Must-read for many reasons). That is to start with prior evidence. Rather than making your estimate, start with "How long did it ACTUALLY take the last time someone did something like this?" and only then modifying the estimate for circumstances.

There is a huge gap between these two methods:

1. "How long does it take an average team to create a SAS product? Maybe a year?" Then modify for "but our team is extra smart, so maybe I'll shorten that to 10 months"

vs

2. "How long will this take? It's not a complicated product, and our team is smart: maybe 4 weeks for feature X, 6 for feature Y, 2 to deploy. I'll even throw in an extra 4 weeks of padding for unknowns, so 16 weeks".

Re: Responding to “Are bugs and slow delivery ok?”

#47

Post by distcs »

userbinator wrote: post #6

Both this article and the one it references only seem to provide more evidence that the descent into mediocrity of the software industry is certainly happening. That said, there's a difference between actual quality, and "quality" as popularised by metrics-driven dogma.

It really saddens me to know that the hacker culture I once so much loved to be part of is rapidly disappearing from the industry.

Re: Responding to “Are bugs and slow delivery ok?”

#48

Post by dasil003 »

The author's insight is fair on a personal level, but the thesis is not very useful as a generalization. The reality is that bugginess and velocity are all relative, and every situation is different. It's good to understand the leadership viewpoint and be realistic about the business that employs you so you can decide if it fits your values and look for a change if not. If you care a lot about the quality of what you produce, there are plenty of companies that need and value that. On the other hand, many people just want a steady job where expectations are clear and ambiguity isn't too high; mediocrity is one way to achieve this, and it can work fine (for a while at least) with sufficient moats.

Re: Responding to “Are bugs and slow delivery ok?”

#49

Post by spacebanana7 »

Most enterprises that fail do so because they run out of money. In software business where the dominant cost is engineering salaries [1], poor tech practices with expensive fixes are a major factor in running out of money.

More abstractly, high productivity engineers help you to exhaust the idea space through delivering products into real world before you run out of money. It's better to fail because you discovered your supposed gold mine had no gold rather because you ran of mining resources half way through.

[1] Notably this doesn't apply to capital intensive business with high marketing or infrastructure costs

Re: Responding to “Are bugs and slow delivery ok?”

#50

Post by thih9 »

csydas wrote: post #29
aaronbrethorst wrote: post #13

This blog post is a response to an advertisement for coaching services. The article it responds to was so content-free and sales-focused that it actually got flagged here on HN. https://news.ycombinator.com/item?id=36615325 I don’t think anyone needs to waste their time arguing with a strawman.

If I scribble a random time stamp on a piece of paper and frame it and call it a clock, it's still right at least once a day (24 hour notation or bust :) ) The original article was just a garbage native advertisement with the wrong conclusion, I agree, but the ideas it stated weren't really wrong; Microsoft is a pretty good example of a company that constantly leaves its products in very buggy states for long periods…

> the original author wasn't wrong that there is a ridiculously high tolerance for buggy, low quality software, and the reason isn't super clear

I disagree. I’d say the reason is clear: the market decides; and the decision is that current amount of bugs is ok. Most software is fine for the end user.

We (devs) notice the bugs because we’re familiar with the process; but in the end we’re just people who know how the sausage is made.

Post reply on HN