Live data from Hacker News

You are never taught how to build quality software

florianbellmann.com

341–350 of 500 posts

Re: You are never taught how to build quality software

#341

I don’t think it can be taught, at least not in a classroom. Apprenticeship and learning from wise mentors in real world environments is the best way to learn.

In my opinion, there's a tiny bit of nuance: it can for sure be taught, but to be internalized requires experience, likely being on the wrong end of something sharp (pager, company going out of business, or you yourself experiencing a bug that otherwise only a customer would see)

Kind of related to https://english.stackexchange.com/questions/226886/origin-of...

Re: You are never taught how to build quality software

#342

You learn this at quality shops. 10-15 years ago roughly FAANG. Today? TailScale and stuff like that. You can just noT have a bunch of pointless micro services and docker in your runc and layer on layer of json de/re, and unit test to get coverage but ignore quickcheck and hypothesis and fuzzing. You can use stacked diffs and run oncall loops out of the team authoring the code and all of it. You can minimize dynamic…

roughly FAANG What does roughly FAANG mean? Today? TailScale and stuff like that. The VPN? You might have some ideas about quality software, but this comment is incomprehensible.

Someone's butthurt about never working for a company with a recognisable name?

Re: You are never taught how to build quality software

#343
post #69

1. The premise that college teaches you how to build software in industry is a pretty wild claim. 2. Is this article from the 90s where we ship software on CDs or floppy disks? In today's world where the concept of a "release" is often blurred by continuous delivery pipelines (and this is considered a good practice), having a quality insurance department manually assuring that no bugs are in that release seems downri…

And then you remember stories like that about Boeing. How their 737 Max has been tested by cheap contractor from India. There are tons of software without continuous delivery.

Absolutely, and industries like medical devices and aviation have extremely strict regulation and procedures regarding the testing of software. The article not mentioning any of those made me conclude that author is referring to regular software.

Re: You are never taught how to build quality software

#344
post #149

Earlier quoted context omitted.

I took one of these kinds of classes in my masters program this year. They were totally obsessed with UML. It would be nice if these classes could move beyond dogma that is decades old.

What would be better? Change tools every 3-5 years like the industry does, so by the time any given instructor actually has a grasp on a particular tool or paradigm, its already obsolete (or at least fallen out of fashion) too? I'm no fan of UML, but the exercise is to teach students how to plan, how to express that plan, and how to reason about other people's plans. The students will certainly draw a lot of flow dia…

I haven't seen a UML diagram once in 7 years of working. The approach presented in the book "a philosophy of Software Design" is much better than the outdated bullshit from the 90s.

Re: You are never taught how to build quality software

#345

Earlier quoted context omitted.

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.

> 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. From a cynical point of view, if those hundreds of thousands of users will use your product despite the bugs, does it matter?

People are only as loyal as their opportunities; if the competition is mostly the same as your product but has either fewer bugs or bugs in a less painful flow, buh-bye

I'm super cognizant that the cited example of "social media company" is its own special ball of wax, due to the network effect, and I wish to holy hell I knew how to fix that bug :-)

Re: You are never taught how to build quality software

#346

Earlier quoted context omitted.

roughly FAANG What does roughly FAANG mean? Today? TailScale and stuff like that. The VPN? You might have some ideas about quality software, but this comment is incomprehensible.

Someone's butthurt about never working for a company with a recognisable name?

How did you get to that? I can't even figure out what the comment I replied to is talking about. It isn't made up of full sentences and real words.

Re: You are never taught how to build quality software

#347
post #69

1. The premise that college teaches you how to build software in industry is a pretty wild claim. 2. Is this article from the 90s where we ship software on CDs or floppy disks? In today's world where the concept of a "release" is often blurred by continuous delivery pipelines (and this is considered a good practice), having a quality insurance department manually assuring that no bugs are in that release seems downri…

Not everyone is writing a webapp where you can roll out upgrades anytime CI passes, or a phone app that you can upgrade every week. some of us work on code that will be shipped in a device that is not easy to upgrade.

Not all software that is frequently updated is a web app. Ask Tesla, Apple, Sonos, Garmin, ...

Anything connected to a network could be released frequently if people wanted to. Not everything is connected to a network though.

Re: You are never taught how to build quality software

#348

Earlier quoted context omitted.

For years a friend tried to get his department (where he worked as a lecturer) to add a software engineering course where the basic syllabus was to (1) receive a TOI from the last semester and the code base, (2) implement some new features in the code base, (3) deploy and operate the code for awhile, and (4) produce a TOI for the next semester. The code base was for a simple service that basically provided virus/malw…

The thing is for academics quality software sometimes isn't actually quality software. My experience has been that people who's first jobs were in companies with quality software or who's job included reading through other people's quality software learn to write good software, the other ones learn whatever they saw in the environments they worked in.

[deleted]

Re: You are never taught how to build quality software

#349

You learn this at quality shops. 10-15 years ago roughly FAANG. Today? TailScale and stuff like that. You can just noT have a bunch of pointless micro services and docker in your runc and layer on layer of json de/re, and unit test to get coverage but ignore quickcheck and hypothesis and fuzzing. You can use stacked diffs and run oncall loops out of the team authoring the code and all of it. You can minimize dynamic…

roughly FAANG What does roughly FAANG mean? Today? TailScale and stuff like that. The VPN? You might have some ideas about quality software, but this comment is incomprehensible.

OP is saying that 10-15 years ago FAANG companies (and a few more) were the only ones writing quality software. Now, FAANG doesn't care anymore but there are new unicorns in the making that do care - TailScale being one of them (debatable)

Re: You are never taught how to build quality software

#350
post #117

We do teach these things, they are just not core CS topics, but rather in other areas, relegated to electives like a software engineering course. At CMU we have entire Master's program for software engineering and an entire PhD program (in my department). We teach exactly the kinds of things the blog post is about, and more. Software Engineering is a whole field, a whole discipline. I get that this is a blog post and…

For years a friend tried to get his department (where he worked as a lecturer) to add a software engineering course where the basic syllabus was to (1) receive a TOI from the last semester and the code base, (2) implement some new features in the code base, (3) deploy and operate the code for awhile, and (4) produce a TOI for the next semester. The code base was for a simple service that basically provided virus/malw…

In my university, (US, state school,) we had a software engineering course exactly like this. It was great in theory, but in practice, the experience was rushed, the codebase was poor quality, (layers upon layers of nothing features with varying code quality,) and the background knowledge was completely ignored. The application we had to work on was a Tomcat Java Web application with an Angular frontend, when neither of those technologies were taught in any other classes (including electives.)

This approach to education can work, but I think simulating/mocking portions of this would have been more helpful (it could've been a teacher/TA managed codebase we started with rather than the monstrosity passed between generations of students who were inexperienced.)

Post reply on HN