Live data from Hacker News

Responding to “Are bugs and slow delivery ok?”

uselessdevblog.wordpress.com

21–30 of 128 posts

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

#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 development is wildly unpredictable. I've never met anybody who could reliably predict how long something would take to develop, even if the requirements were "frozen" and even if they were the person delivering it. I have met people who could predict ahead of time how long it would take them to deliver something, but what they delivered always had "bugs" (either actual incorrect behavior, or edge cases that nobody thought of until they actually used the software) that themselves took an unpredictable amount of time to fix.

2) No organization can ever accept any amount of unpredictability. Every "advance" in software development I've ever seen has claimed to (implicitly or explicitly) remove the inherent unpredictability in software development, although none have actually delivered. They're fine with spending months in planning meetings while not actually developing anything tangible as long as those planning meetings provide the illusion of predictability.

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

#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 to have, but is not the be-all-and-end-all.

while being mostly true in all other cases I don't think it does it justice what mediocrity actually means for everyone involved. I have seen very varying levels of quality requirements/enforcement, testing, delivery speed and eventual bugs at different costs at different companies. And I in general found that higher quality software and less bugs were associated with much happier and more productive developers. And I would make the argument that less happy developers => more turnover => more second order costs. So while it might not make or break the company it certainly has a negative impact on profits downstream. And for customers too. Vendor lock in is a great thing for a company to profit from but if you really make a shitty product it opens up a lot of venues for competitors to eventually canibalize your market or from users to jump ship the next time they can. Take MS Teams for example. Lots of lock in but trust me the second better competitors are on the table I vigorously fight to switch. It's a slow burn but a burn nonetheless.

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

#23
I have, for the record, seen companies lose market share, commercial opportunities, and once have to go through financial restructuring due to missing product goals.

Technical debt / quality / boneheadedness was at least a factor in each case.

I've also worked in financial services where a bad enough bug can and will lose you your (jurisdiction-appropriate) license to to do business.

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

#24

> 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 purely digging ourselves out of that hole, with all new development paused, and all hands on limping the ship along. I would say, that bug was very close to ending us. Luckily, we never disappointed in a similar way since.

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

#25

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…

We are all at the mercy of Hofstadter's Law.

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

#26

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.

Maybe, just maybe, the best people to build complex software systems that serve millions of people aren't the ones who can do the most leetcode problems.

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

#27

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 classic case study.

https://en.wikipedia.org/wiki/Therac-25

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

#28
The core of this argument is really about the emotional health of the workers.

An emotionally healthy person tends to want to maintain their environment. It doesn't do anything objective to have nice furniture and pretty paintings, but you like it in your house. You want to feel at peace, so you adjust little things...the kitchen would be nicer with the plates in a pile over here instead of just pulling them out of the dishwasher.

At work, you're the householder of a million technical details, and to feel good about it you want to maintain your environment! If that window has an ugly redraw you want to recode it, if the ribbon has big ugly icons you want to collapse it into a strip menu, if the email client freezes whenever WiFi gets spotty you get annoyed because the code is still from 1995 under the surface. The software you're making and using, in service to your own craft, has an effect on you. If it makes you feel ugly, you want to fix it. This blog post -- which probably wasn't written on company time -- is here because someone needed to reorganize their thinking to feel emotional health. I think we should insist on doing a better job than just sacrificing our work to feed the money machine, even if our self-described jobs are just to turn funding into paychecks.

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

#29

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 of time, and it expects you to use the products in that state. (read: pay Microsoft) They're still dominating. While I admire the ReFS team for what they pulled off, the first 2 years it was virtually unusable if you tried to use it like they told you to, either due to memory leak bugs or outright corrupting your data silently.

It still got used and was one of the common deployments for MS SQL and Exchange during that time.

The original article doesn't sell a solution, it sells some spin from the author, but 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. These aren't cheap services either, they're billion dollar companies that can barely keep the services running sometimes or are incredibly slow to react to missing features or features not working well/correctly.

I think this situation merits discussion.

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

#30

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

Agree. For example, pg said that ViaWeb was successful because they had put care into their code, which allowed them to iterate quickly and integrate new features that customers requested. Whereas competitors were held back by their cumbersome code and slow cadence of releasing features.

pg would say that, though, because it was his company and it worked out for him.

But maybe he was actually wrong about quality being a differentiator, and his competitors could've shipped features with shitty code but had other problems.

Post reply on HN