Live data from Hacker News

You are never taught how to build quality software

florianbellmann.com

101–110 of 500 posts

Re: You are never taught how to build quality software

#101

> It will be necessary to deliver software without bugs in time. Seems like a pretty bad premise to start an article on quality software. If you believe you can ship bug free code, it's time to switch careers.

It's perfectly acceptable to let bugs escape into production if those "cost" of fixing that bug higher than the "cost" to the user experience / job to be done. A bug that takes a week to fix that will only be encountered by a small amount of users in a small number of obscure scenarios may not need to be fixed.

I think a common error is taking this view in isolation on each bug.

Fact is, if you ship enough 'low probability' bugs in your product, your probabilities still add up to a point where many customers are going to hit several of them.

I've used plenty of products that suffer from 'death by a thousands cuts'. Are the bugs I hit "ship blockers"? No. Do I hit enough of them that the product sucks and I don't want to use it? Absolutely.

Re: You are never taught how to build quality software

#103

> It will be necessary to deliver software without bugs in time. Seems like a pretty bad premise to start an article on quality software. If you believe you can ship bug free code, it's time to switch careers.

Spicy take on engineering. Why do we accept this for software when do not accept the same in other engineering domains?

>when do not accept the same in other engineering domains?

No, you just complain that your taxes are being used to build expensive roads and bridges. Or you think airplanes are far too expensive. Or that new cars are insanely expensive.

There are cost trade offs. In general, better quality more expense.

Also in software there is not an excessive amount of software engineers in relation to demand for software. So SWEs can get paid a lot to go build crappy software.

Re: You are never taught how to build quality software

#104
post #91

Earlier quoted context omitted.

I agree with you in principle, but it's very easy to have this attitude when the education isn't obscenely expensive. Which is why the "I'm never going to use this, what a waste of time" feeling among American undergrad students is so common. If you fix the affordability problem and bring it back to where is was in the mid 70s (inflation adjusted) I think things would be a lot better.

My point is that higher education isn't job training and doesn't pretend to be, and people who think it is or should are the ones that need education the most because they don't seem to get it.

> and doesn't pretend to be

I'm not sure about this part... A very common pattern in my conversations with working class friends and family from my parents' generation is: "we were told that if we sent our kids to college, they'd have better lives than we did, but instead we all just ended up with more debt than we could handle".

It's tricky! If you tell teenagers and their parents the truth - this purely academic program will not train you for any job besides pure academia, which, while it can be a fantastic career, is a super risky hits business in which only a few will truly succeed - then that's only going to sound like a reasonable risk to take for wealthy families. But then you've badly limited your pool of academic researchers to this extremely small and honestly often not as promising set of rich kids.

Maybe one solution (which is not workable in the real world) would be: any academic program that does not have a viable "job training" component should only accept students on academic scholarship, regardless of their own means. If some neutral party thinks they are promising enough in that field to pay their way, they get to go for free, otherwise they don't get to go at all. The programs that do graduate people with directly marketable job skills could keep working the current mercenary way.

The reason this wouldn't work in reality is that the wealthy would still just game the scholarships in some way. Alas.

Re: You are never taught how to build quality software

#106

> It will be necessary to deliver software without bugs in time. Seems like a pretty bad premise to start an article on quality software. If you believe you can ship bug free code, it's time to switch careers.

Spicy take on engineering. Why do we accept this for software when do not accept the same in other engineering domains?

There are a few aspects. One is that we don't understand the fundamentals of software as well as the underpinnings of other engineering disciplines.

More importantly though, for the most part we choose not to do engineering. By which I mean this - we know how to do this better, and we apply those techniques in areas where the consequences of failure are high. Aerospace, medical devices, etc.

It differs a bit industry to industry, but overall the lessons are the same. On the whole it a) looks a lot more like "typical" engineering than most software development and b) it is more expensive and slower.

Overall, we seem to have collectively decided we are fine with flakier software that delivers new and more complex things faster, except where errors tend to kill people or expensive machines without intending to.

The other contributing thing is it's typically vastly cheaper to fix software errors after the fact than, say, bridges.

Re: You are never taught how to build quality software

#107
post #101

Earlier quoted context omitted.

It's perfectly acceptable to let bugs escape into production if those "cost" of fixing that bug higher than the "cost" to the user experience / job to be done. A bug that takes a week to fix that will only be encountered by a small amount of users in a small number of obscure scenarios may not need to be fixed.

I think a common error is taking this view in isolation on each bug. Fact is, if you ship enough 'low probability' bugs in your product, your probabilities still add up to a point where many customers are going to hit several of them. I've used plenty of products that suffer from 'death by a thousands cuts'. Are the bugs I hit "ship blockers"? No. Do I hit enough of them that the product sucks and I don't want to use…

Software is commonly built on non-fungible components and monopolies.

Right, you don't want to use Microsoft Word, or SalesForce, or Apple vs Android, or X Whatever. It's highly unlikely you'll have a choice if you use it though.

Re: You are never taught how to build quality software

#108

> It will be necessary to deliver software without bugs in time. Seems like a pretty bad premise to start an article on quality software. If you believe you can ship bug free code, it's time to switch careers.

Yep. If you have written production grade software at real companies, you know that the moment you make that new commit (even if 1 liner change), you are now ready to accept that it could break something. yes you can do your unit tests, integration test, User Acceptance Tests and what not. But every code change = new possible bug that you may not be able to catch until it occurs to a customer. Whenever I hear a devel…

How about a formal proof? :)

I jest, but that should be the gold standard for anything life-critical and good to have for mission-critical software. Alas, we're not there yet.

Re: You are never taught how to build quality software

#109
post #106

Earlier quoted context omitted.

Spicy take on engineering. Why do we accept this for software when do not accept the same in other engineering domains?

There are a few aspects. One is that we don't understand the fundamentals of software as well as the underpinnings of other engineering disciplines. More importantly though, for the most part we choose not to do engineering. By which I mean this - we know how to do this better, and we apply those techniques in areas where the consequences of failure are high. Aerospace, medical devices, etc. It differs a bit industry…

The modern car contains within it a perfect example the dichotomy:

1. The ECU ("hard" engineering)

2. The infotainment system ("soft" engineering)

Now, an interesting thing I have noticed is that "soft" software engineering pays more. Often substantially more.

Re: You are never taught how to build quality software

#110
post #95

Earlier quoted context omitted.

Spicy take on engineering. Why do we accept this for software when do not accept the same in other engineering domains?

Trust me when I say this: even "other" engineering domains have to do patches. The difference is that software can be used before it is fully ready, and it makes sense to do so. No one can really use a 90% finished power plant, but software at 95% capacity is still usually "good enough"

e.g. product recalls?
Post reply on HN