Live data from Hacker News

You are never taught how to build quality software

florianbellmann.com

71–80 of 500 posts

Re: You are never taught how to build quality software

#71
post #66

I wonder how much of the lack of QA is rational. That is to say, for most projects does shipping with lots of somewhat hard-to-find bugs actually hurt the bottom line? For some classes of bugs it can (e.g. if the software is so bad as to open you to a class-action lawsuit; in b2b software bugs that put you in breech of contract), but for many classes of consumer software, it's not clear to me that shipping software t…

It starts mattering more for consumer software when you reach mass scale. Somewhat hard-to-find bugs at the scale of hundreds of millions of users (like a social media company), turn into bugs faced by hundreds of thousands of users.

But at that scale (in my experience), QA is up front and center and is typically a core pillar of engineering orgs.

Re: You are never taught how to build quality software

#72

Earlier quoted context omitted.

there is no such thing as zero bugs. There is only a marker in time for a suite of tests that show no bugs. Doesn't mean larva aren't living under the wood. You can't control all the bits (unless you built your own hardware/software stack).

I think we're saying the same thing? That was my point. You're never going to achieve zero bugs no matter how much time you give yourself. Focus on getting the critical path right and creating a good experience, and then get it to customers for feedback on where to go next. [The above does not necessarily apply in highly regulated industries or where lives are on the line]

Yup, I also like how you call out "get it in-front of customers" as a step in the whole chain. Often sorely missed. Sometimes a bug to you, is a feature to them (gasp!)... so either make it a first class thing or train them on the correct path (while you fix the "bug").

Re: You are never taught how to build quality software

#73

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.

This presupposes that you know what/where bugs will be found and how they'll impact future users. In my experience knowing either of these is very rare at the point where you're "building quality".

>how they'll impact future users

Most people in this thread understand that users' interests only matter insofar as they impact business profit.

I just think you're having a different conversation.

Re: You are never taught how to build quality software

#74
post #67
post #57

Earlier quoted context omitted.

Here is one, https://swc.rwth-aachen.de/teaching/courses/2022-summer-seme...

I don't know. I was hoping for something like: "We know inheritance is bad because when we convert the typical example over to this special graph it forms a non-compact metric space" Or something like that. Even though I find cyclomatic complexity uncompelling, it at the very least can slurp up code and return a value. Nicely objective, just not particularly useful or insightful to whether or not things are easy to u…

If you want numbers and research like content, that is available as well.

"Measuring Complexity of Object Oriented Programs"

https://link.springer.com/chapter/10.1007/978-3-540-69848-7_...

Re: You are never taught how to build quality software

#75
post #28

There are Computer Engineering programs and a few universities that really emphasize internships and hands on practice. But at many universities, the CS department came out of the Math department and is focused on theory. Chemistry isn't Chemical Engineering either. I think that's okay. University isn't just a trade school--the idea behind almost any degree is to train the mind and demonstrate an ability to master co…

What society needs is a mix of trade school a traditional university. If a university is not providing both they are failing everyone. (except the straw-man rich kid who will inherit a lot of money but not be expected to either also inherit/run a company or pass the money onto their kids - this is something that happens in story books but doesn't seem to be real world where the rich give their kids lots of advantages…

> If a university is not providing both they are failing everyone.

Why?

> A pure university education without considering is this degree useful in the real world is a disservice to education.

I think this line of thinking is a much bigger disservice to higher education. It was very tiresome as an undergraduate to be surrounded by people that thought this way - and detrimental to everyone's education.

"I'll never use this knowledge" is the single worst thing you can say as a student, and it needs to be beaten out of undergrads' heads. Not encouraged.

Re: You are never taught how to build quality software

#76

Earlier quoted context omitted.

> Is there any human activity where quality is an attribute successfully taught? Every industrial practice. On the other hand, the title just means that programming is not an industrial practice. What should be obvious to anybody that looked, but some people insist on not seeing it.

Yeah and you can see other disciplines like Aviation where there are so many incredible processes to ensure learning and constant improvement.

Will you please elaborate?

Re: You are never taught how to build quality software

#77
post #75
post #28

Earlier quoted context omitted.

What society needs is a mix of trade school a traditional university. If a university is not providing both they are failing everyone. (except the straw-man rich kid who will inherit a lot of money but not be expected to either also inherit/run a company or pass the money onto their kids - this is something that happens in story books but doesn't seem to be real world where the rich give their kids lots of advantages…

> If a university is not providing both they are failing everyone. Why? > A pure university education without considering is this degree useful in the real world is a disservice to education. I think this line of thinking is a much bigger disservice to higher education. It was very tiresome as an undergraduate to be surrounded by people that thought this way - and detrimental to everyone's education. "I'll never use…

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.

Re: You are never taught how to build quality software

#78
post #68

Earlier quoted context omitted.

> But the goal is “better, always better, what can I do better?” Is that not the case in software? The incentive to improve may not be quite as strong as in aviation (crashing software isn't quite the same as crashing airplanes), but it is still pretty strong. Life is very miserable in software when quality isn't present.

What happens when you work under a group of people who are satisfied at stage one of project X? You know you can iterate to get two stages further, but they want you to work on projects Y and Z. This is a very common situation where you, or even the whole development team has very little control. Of course, management should be supportive of quality improvements, but their reality is either one where they are under g…

[deleted]

Re: You are never taught how to build quality software

#79
post #70
post #50

Earlier quoted context omitted.

This is false. Its just that the costs of low quality code are much less obvious and harder to measure then the dev time. But the ammount of bad code just piles on itself over and over and over and we end up in a world where hardwares becomes incrementally faster while software becomes slower and slower, and more bugier. I mean, in the strict sense of the world an individual company will not pay those costs, but on a…

> This is false. I wonder where you get the confidence to make such a strong statement, which is clearly not warranted. I want to challenge you to broaden your view a bit: Not a lot of software is like Windows explorer. Not a lot of software is performance critical. A lot of software can do with bugs, with many many bugs, to be honest. A lot of code is run fewer than 100 times, before it's retired. Also, not a lot of…

>Not a lot of software is performance critical.

Not being performance critical doesn't mean it is justified to diss-respect users by wasting their time.

>A lot of code is run fewer than 100 times, before it's retired. Also, not a lot of software written has many users.

Obviously we aren't talking about some simple automation scripts here.

>"Pollution" often affects just the author of the software themself.

You are misunderstanding the pollution analogy. I'm not talking about polluting the codebase with code smell.

I am talking about costs of low quality being non obvious and only revealing themselves at global scale

Re: You are never taught how to build quality software

#80
post #79
post #70

Earlier quoted context omitted.

> This is false. I wonder where you get the confidence to make such a strong statement, which is clearly not warranted. I want to challenge you to broaden your view a bit: Not a lot of software is like Windows explorer. Not a lot of software is performance critical. A lot of software can do with bugs, with many many bugs, to be honest. A lot of code is run fewer than 100 times, before it's retired. Also, not a lot of…

>Not a lot of software is performance critical. Not being performance critical doesn't mean it is justified to diss-respect users by wasting their time. >A lot of code is run fewer than 100 times, before it's retired. Also, not a lot of software written has many users. Obviously we aren't talking about some simple automation scripts here. >"Pollution" often affects just the author of the software themself. You are mi…

> Obviously we aren't taking about some simple automation scripts here.

This is moving the goalpost, and also ignores the fact that software exists on a spectrum from "simple automation script" to "messaging app used by millions". It seems you have a very narrow view of what software is, or what it is used for, and the constrains that apply when building it.

Post reply on HN