You are never taught how to build quality software • Hacker News Board

Re: You are never taught how to build quality software

#481

Post by philipwhiuk » Sun, Dec 10, 2023, 4:32 PM UTC

fidotron wrote: post #213

bluGill wrote: post #185

Earlier quoted context omitted.

Most devices work within the spec 99.9% of the time, but that last .1% it is outside the spec. The exact % is different for different projects of course, but the idea is still there: no software operates according to spec 100% of the time.

It does though. My example of adding two ints within a known finite range would operate to spec 100% of the time. You would have to introduce things like tolerance to hardware failure, but that is outside the spec of the software as stated.

> You would have to introduce things like tolerance to hardware failure, but that is outside the spec of the software as stated.

No-one in the real world gives a damn about your 'spec of the software as stated'

Re: You are never taught how to build quality software

#482

Post by hnfong » Sun, Dec 10, 2023, 4:38 PM UTC

roenxi wrote: post #153

Gare wrote: post #108

Earlier quoted context omitted.

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.

As always, the branding of formal methods sucks. As other commentators point out, it isn't technically possible to provide a formal proof that software is correct. And that is fine, because formal software methods don't do that. But right from the outset the approach is doomed to fail because its proponents write like they don't know what they are talking about and think they can write bug-free software. It really sh…

> It really should be "write software with a formal spec".

The code is already a formal spec.

Unless there are bugs in the language/compiler/interpreter, what the code is essentially formally well defined.

As programming languages get better at enabling programmers to communicate intention as opposed to being a way to generate computer instructions, there's really no need for a separate "spec". Any so called "spec" that is not a programming language is likely not "formal" in the sense that the behavior is unambiguously well defined.

Of course, you might be able to write the "spec" using a formal language that cannot be transformed into machine code, but assuming that the "spec" is actually well defined, then it's just that "compiling" the spec into machine code is too expensive in some way (eg. nobody has written a compiler, it's too computationally hard to deduce the actual intention even though it's well defined, etc.). But in essence it is still a "programming language", just one without a compiler/interpreter.

Re: You are never taught how to build quality software

#483

Post by tasuki » Sun, Dec 10, 2023, 7:04 PM UTC

akoboldfrying wrote: post #401

accurrent wrote: post #363

Earlier quoted context omitted.

The university I went to had this. We had to maintain an application that was built by our seniors and then hand that off to the next batch.

I'm impressed by the closeness to reality, but curious how they could assess performance consistently?

"the students are getting worse every year"

Re: You are never taught how to build quality software

#484

Post by cloths » Sun, Dec 10, 2023, 8:19 PM UTC

From one point I think it's fair for Uni emphasise on CS over SE because there's "truth" inherent in CS, but for SE, which deals with building software in real life, is more complicated because real-life is complicated.

Even for the QA advice in the post "writing tests as you write the software" one can argue it's infeasible/inappropriate for my type of project and/or with the people who work on this project.

So my two cents on this is let Uni teach the students *to be aware of* all the SE principles and best practices this industry now have, like the tools in your toolbox, also let us know that whether to use them in real-life projects, need assessment of situation, cost/value balance, people etc, afterall not everybody works on dream projects.

Re: You are never taught how to build quality software

#485

Post by BobaFloutist » Sun, Dec 10, 2023, 9:11 PM UTC

zamalek wrote: post #459

BobaFloutist wrote: post #64

Earlier quoted context omitted.

I like to think of "zero bugs" as the asymptote. As you spend more time, you discover increasingly fewer (and less significant) bugs per unit of time. POSSIBLY at the limit of infinite time you hit 0 bugs, but even if you could, would it be worth it? Doubtful. I can think of far better ways to spend infinite time.

0 bugs is actually impossible. A cosmic ray can flip a bit and change the behavior of your software. We live in a fundamentally unreliable universe. We aren't taught how to write reliable software because very few people know how to write reliable software. It doesn't help that academia has a hard crush on OOP, which is a bag of accidental complexity - and complexity is a breeding ground for unreliability.

I think if a cosmic ray flips the bit and changes the behavior of your software, you can still reasonably brag that you wrote 0-bug code. It's not your fault that happened, you didn't do that. The code you wrote had 0 bugs.

Re: You are never taught how to build quality software

#486

Post by colinmorelli » Sun, Dec 10, 2023, 10:00 PM UTC

ElectricalUnion wrote: post #61

colinmorelli wrote: post #43

Earlier quoted context omitted.

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]

I would say that also applies on highly regulated industries or where lives are on the line. On those you're of course expected to do safety and testing up to the limit of the "value of a statistical life"s within the expected project impacts, but it still has time and budget limits.

The part I was suggesting does not apply is the statement "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."

Most software engineering is about making sure the happy path works well. When lives are on the line, you need to also plan to minimize the possible damage that can happen when things go wrong.

Re: You are never taught how to build quality software

#487

Post by Fire-Dragon-DoL » Sun, Dec 10, 2023, 11:41 PM UTC

I think there is a spectrum, it depends on the software it needs to be delivered and the need for business. A clear example are single player videogames, where the cost of automated testing is so high and the software has so little value after the sale that manual testing is a better option

Re: You are never taught how to build quality software

#488

Post by hackertyper69 » Mon, Dec 11, 2023, 1:23 AM UTC

bluGill wrote: post #468

jupp0r wrote: post #347

Earlier quoted context omitted.

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.

There is a long list of both. Some things should not roll out updates without extensive testing, including manual testing to verify nothing was missed.

like airplanes

Re: You are never taught how to build quality software

#489

Post by idlephysicist » Mon, Dec 11, 2023, 2:11 AM UTC

spiffytech wrote: post #478

heelix wrote: post #276

Earlier quoted context omitted.

I've wished that students would be required to hand their semester long project to the person next to them each week.

My university did this - each semester's class inherited the code base the last semester had worked on. As a learning tool it was a disaster. The code had never been touched by a skilled engineer, just years of undergrads pulling all-nighters. That meant it didn't teach what good maintenance looked like. Students just piled their hacks on top of someone else's hacks so they could hit the deadline. It wasn't a good wa…

> ... just piled their hacks on top of someone else's hacks so they could hit the deadline.

This sounds oddly familiar... hmm.

Re: You are never taught how to build quality software

#490

Post by idlephysicist » Mon, Dec 11, 2023, 2:37 AM UTC

Communitivity wrote: post #230

There is a corollary. You need to learn how to build quality software. You also need to know what level of quality vs completeness tradeoff you need to make. Imagine I have a deadline of Jan 15th to demo features x, y, and z to senior leadership (who then will make funding decisions that could impact my project), and I get to Jan 15th with x, y, and not z - or worse, none of them working fully. But the code quality i…

Exactly, there's no point in a startup having _perfect_ code, great test coverage, and an excellent CI/CD pipeline if they've not gotten to market before the cash runs out.

Though I think that if leadership are not consulting the Engineers on timelines, instead just dictating the timelines to them, then there is a massive problem afoot.