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

51–60 of 128 posts

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

#51

Post by drewcoo »

Escapado wrote: post #22

And even though the points raised are mostly valid I think there is a lot of nuance to this. If you write control software for medical devices this is simply not true. Same goes if you handle incredibly sensitive data or critical infrastructure or assistance systems for air travel and you can probably come up with a a bunch more cases where bugs are not ok. And also I think this sentence > Where high quality is nice…

The examples you give have regulations for software. Even if companies want to "move fast and break things," with medical devices there are required tests and the testing and results are audited by the feds (here in the US), so you're forced to move slowly and not be broken (in ways that are regulated).

That does not mean "high quality." You can still have an architecture that's tightly-coupled spaghetti code that resists all human efforts at debugging. It just means "we threw enough paperwork at the auditors that they're not asking for more."

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

#52

Post by nmilo »

jchw wrote: post #40
ryandrake wrote: post #11

Earlier quoted context omitted.

“My company didn’t go under” is pretty much the lowest bar you can shoot for. This blog post is saying “Staying healthy doesn’t matter because neither I nor anyone I know died so far.”

This analogy is a bit tortured but it's honestly pretty good anecdata that something probably doesn't generally kill you if you've been around people doing it for 15 years and none of them have died yet. It can kill you, but that doesn't mean it generally does. I'd love to come to the conclusion that it's wrong, but it's right. Most companies absolutely 100% can afford to ship bugs: the proof? They're doing it, they…

People smoke from 15-20 years old but still don't die in their 30s. It doesn't mean it's not bad for your health. This is the same thing, it's bad for the health of the company. High dev turnover, poor working conditions, and productivity issues can all lead to a death from a thousand cuts, and even if the company doesn't actually go under, you can't say that a company didn't suffer because of it.

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

#53

Post by WaitWaitWha »

No, both this and the original blog entry are myopic.

There have been companies that went out of business, not only the software publisher but companies that relied on such software.

If the assertion is that "known unknown" bugs exist in code, and the publishers are aware that there might be bugs but in their QA/QC could not identify them, I can accept it. But, if the assertion is that there are "known known" bugs exists, I find it bordering unethical. The only way I can accept this if the publishers informs the buyer, and let them know what is the impact, the plan of action to remediate or mitigate the bug, and in what time frame.

"Known known bugs" (the publisher knew about the bug for extended period of time, and never informed the users) have destroyed multitude of businesses.

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

#54

Post by wokwokwok »

So, here’s a simple game:

- take a blank piece of paper (this is “the software”)

- pick two random points on the paper roughly 3 inches apart (“a requirement”)

- draw a line between the two points; the line cannot cross any other line (“the implementation”).

Repeat the exercise multiple times.

You’ll quickly learn that unless you have a “system”, drawing a three inch line goes from taking about 2 seconds, to taking 10, 15 or 30 seconds, despite “the requirement complexity” being exactly the same every time.

Now try playing with people taking turns. :)

I like playing this game with people who think that writing bad code is fine, or that they can work by themselves and not worry about what other people do as long as “their own” code is good.

You can still solve pretty much any problem with enough time and effort; but if you don’t have a “system” for good organisation, eventually, you’ll be struggling to solve basic problems because of layered unmanageable requirements, no matter how smart or capable you are.

…it’s not about shipping bugs, it’s about fundamentally reducing the speed of delivery over time, incrementally, in an unbounded fashion that eventually makes systems impossible to make changes to without compromising on requirements.

(Obviously the game is contrived, but it works very well in explaining why past requirements some times have to go away to business people in my experience).

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

#55

Post by watt »

qingcharles wrote: post #45
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 Pro…

If the code you write is uncovering bugs in compiler, you literally are too smart for your own good. Fwiw, I have seen how compilers are made. Makes me amazed anything actually compiles and runs.

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

#56

Post by II2II »

> Software doesn’t make or break an organization.

As someone who works for an organization that is on the receiving end of bad software, I can assure you this is not the case. There is lost opportunity, due to decreased productivity and outright lost clients. There is a souring of the work environment, an environment where people are constantly putting out fires and there is constant churn in staff because of that.

Perhaps the organization I work for is unique in that it is public sector and cannot go out of business (which appears to be the author's definition of broken). Perhaps the author has never dealt with software where edge cases involving lost and phantom data is a daily norm. Clients, real people with real lives, are literally lost by the system.

Things are so bad that losing several years of business records (or, more likely, paying to have them maintained by a retired system for some legally defined period) is considered as a viable option.

So yes, buggy software does break organizations.

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

#57

Post by commandlinefan »

embwbam wrote: post #46
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"…

> How long did it ACTUALLY take

Haha, I came to that same conclusion decades ago - I don't know if it would actually produce meaningful estimates or not, though, because every time I try to estimate that way, somebody more "important" than me comes along and throws out that estimate for one that fits the timeline he already had in mind.

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

#58

Post by jchw »

nmilo wrote: post #52
jchw wrote: post #40

Earlier quoted context omitted.

This analogy is a bit tortured but it's honestly pretty good anecdata that something probably doesn't generally kill you if you've been around people doing it for 15 years and none of them have died yet. It can kill you, but that doesn't mean it generally does. I'd love to come to the conclusion that it's wrong, but it's right. Most companies absolutely 100% can afford to ship bugs: the proof? They're doing it, they…

People smoke from 15-20 years old but still don't die in their 30s. It doesn't mean it's not bad for your health. This is the same thing, it's bad for the health of the company. High dev turnover, poor working conditions, and productivity issues can all lead to a death from a thousand cuts, and even if the company doesn't actually go under, you can't say that a company didn't suffer because of it.

I'm going to be honest, this analogy is just not that good. You can draw some parallels to cancer and bad workplace culture, but it's a very skin-deep/awkward comparison in my opinion.

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

#59

Post by embwbam »

commandlinefan wrote: post #57
embwbam wrote: post #46

Earlier quoted context omitted.

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

> How long did it ACTUALLY take Haha, I came to that same conclusion decades ago - I don't know if it would actually produce meaningful estimates or not, though, because every time I try to estimate that way, somebody more "important" than me comes along and throws out that estimate for one that fits the timeline he already had in mind.

Lol, you’re not wrong. It’s pretty clear organizations prefer the illusion of getting something quickly to accurate information

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

#60

Post by unmole »

watt wrote: post #55
qingcharles wrote: post #45

Earlier quoted context omitted.

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

If the code you write is uncovering bugs in compiler, you literally are too smart for your own good. Fwiw, I have seen how compilers are made. Makes me amazed anything actually compiles and runs.

> If the code you write is uncovering bugs in compiler, you literally are too smart for your own good.

It's been a while so I don't remember all the details but I remember an ancient version of gcc refusing to accept perfectly valid zero initialisation of structs. Not terribly exciting but you don't have to be too clever to hit compiler bugs.

Post reply on HN