Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You are never taught how to build quality software

florianbellmann.com

Post reply on HN
Print view View original

471–480 of 500 posts

Re: You are never taught how to build quality software

#471

Post by sanderjd »

fidotron wrote: post #454
sanderjd wrote: post #442

Earlier quoted context omitted.

As you alluded, in practice no specs fully specify a truly bug free implementation. If you want to consider bugs that are within the specification as being bugs in the spec rather than bugs in the implementation, fine, but in my view that is a distinction without a difference. (Personally, I think code is itself more analogous to the specification artifacts of other professions - eg. blueprints - and the process of c…

> in practice no specs fully specify a truly bug free implementation. Except for ones that do, obviously. The key reason to make the distinction is because the fuzzy business of translating intention into specification needs to be fully accepted as an ongoing negotiation process of defining exactly what the specification is, and integrated into repeated deterministic verification that that is what has been delivered.…

Those don't exist. There are too many free variables. Some get much closer than others (for instance via formal verification), but all specs are by necessity a model of reality, not the full reality itself.

Nobody actually has any trouble knowing what a bug is. Like, this is just a non-issue, I've never in my career spent a non-negligible amount of time debating with anybody whether something is or isn't a bug. We discuss whether fixing bugs have worthwhile return on investment, and we discuss the relative priority between fixing bugs and doing other things, but this meta-debate about "well technically it complies with this spec so is it even a bug, really?" just never comes up. We all know what bugs are.

Re: You are never taught how to build quality software

#472

Post by sanderjd »

fidotron wrote: post #452
sanderjd wrote: post #450

Earlier quoted context omitted.

Yes, but that's not real software.

https://en.wikipedia.org/wiki/No_true_Scotsman

Some people obviously aren't true Scotsman... I'm from the US and have no attachment to Scotland; if I claimed to be a Scotsman and you pointed out that I'm not, and I said "well that's just the no true Scotsman fallacy!", then I would be totally full of it.

In the same way I am not a real Scotsman, your toy example of an easily specified snippet of a function that doesn't do anything useful is not real software.

Re: You are never taught how to build quality software

#473

Post by doubloon »

3abiton wrote: post #255
titzer wrote: 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…

What does research in this field look like?

i feel like the Toyota Production System could be applied, I know they used some of it at Amazon but in general I don't hear much about it in 'software spaces'. It's been studied a huge amount in quality theory but... seems like theres not a lot of crossover between manufacturing and software.

like the idea of a Poke Yoke could cover all manner of automated analysis software tools. from the -Wall in gcc to, Rust borrow checker, basically just Poke Yoke.

Re: You are never taught how to build quality software

#474

Post by rurban »

If you study coding at your university, you will be a stupid code monkey. However on proper universities you'll study much less coding, but Software Engineering or Computer Sciences, which teaches engineering and science. Not just QA, also mathematical foundations, writing proofs, writing science papers, writing compilers, doing AI, understanding HW, doing proper project management, with plans and tests.

Pity that he didn't go to a proper uni. Writing quality software is a solved problem, just not applied in most companies.

Re: You are never taught how to build quality software

#475

Post by PeterisP »

Solvency wrote: post #429
anacrolix wrote: post #284

Earlier quoted context omitted.

I have news for you... He's not wrong. The porcelain is different, but the same methodologies and processes are in place. The biggest change recently is distributed (mostly ignored) version control, that's 20 years old, and continuous integration/development (probably also around 20 years old, but only catching on in the last 10-15 years). Computer science has changed more, there are lots of developments in the last…

So you're not a JS developer. Got it.

If you switch to a different framework that does the same things slightly differently and makes something more convenient, and do that three times over the years, that's still perfectly consistent with "Software hasn't changed in the last 10 years" - it's simply not a meaningful change, nor would be switching to a different programming language.

Re: You are never taught how to build quality software

#476

Post by PeterisP »

rvdginste wrote: post #421
__loam wrote: post #344

Earlier quoted context omitted.

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.

I never got the hate against UML. To me, UML is just a language to communicate about several aspects of a technical design, and to visualize a technical design to make it easier to reason about it. I did not read the book "a philosophy of software design", but I just scanned the table of contents, and it is not clear to me how "a philosophy of software design" contradicts with using UML. Are you telling me that in th…

UML is a tool to do something (namely, formal and detailed specification of systems) that in many places nowadays isn't really done. I think it is totally plausible that over 7 years of professional work OP has never been in a situation where one person has made a detailed design and wants to present it in a formal manner to other people in the team using diagrams (as opposed to answering specific questions of "what does this particular thing in the code do"). If they discuss the process, they tell about the process without using an activity diagram. If someone wants to view a database diagram, they use some tool that autogenerates one from the data, and discards it after viewing instead of attempting to maintain it as a formal documentation.

I agree that all those diagrams are also very useful to explain the whole software system to people who are new on the project, however, that doesn't imply that having this ability is common, many (IMHO most, but I don't have the data) companies intentionally don't put in the time and effort to maintain such up to date diagrams for their systems.

Re: You are never taught how to build quality software

#477

Post by PeterisP »

stephendause wrote: post #274
3abiton wrote: post #255

Earlier quoted context omitted.

What does research in this field look like?

So I have not done research any software engineering field and have not read all that much either. One example that comes to mind from one of my courses that I took in software engineering is research around mutation-based testing. That form of testing is where you generate random variants of your test by doing things like deleting a statement, adding a statement, changing a less than sign to a greater than sign, etc…

It looks like you're talking about fuzzing, which has applications in both reliability and security testing.

Re: You are never taught how to build quality software

#478

Post by spiffytech »

heelix wrote: post #276
hardwaregeek wrote: post #160

Earlier quoted context omitted.

There's a massive gap between taught at CMU and taught at most universities. And even if it is taught, it's usually outdated or focused on very literal stuff like how to write web applications. I'd have killed for a class that actually focuses on implementation, on teamwork, on building complicated systems.

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 way to learn to write quality software (even if reality sometimes looks this way).

It was also the only software engineering course in our CS curriculum.

Re: You are never taught how to build quality software

#479

Post by stephendause »

PeterisP wrote: post #477
stephendause wrote: post #274

Earlier quoted context omitted.

So I have not done research any software engineering field and have not read all that much either. One example that comes to mind from one of my courses that I took in software engineering is research around mutation-based testing. That form of testing is where you generate random variants of your test by doing things like deleting a statement, adding a statement, changing a less than sign to a greater than sign, etc…

It looks like you're talking about fuzzing, which has applications in both reliability and security testing.

No, mutation-based testing is different. Fuzzing varies the input to the program. Mutation testing varies the program itself as a means of testing the quality of the tests.

https://en.m.wikipedia.org/wiki/Mutation_testing

Re: You are never taught how to build quality software

#480

Post by hnfong »

MaxBarraclough wrote: post #206
cochne wrote: post #138

Earlier quoted context omitted.

I never really got how proofs are supposed to solve this issue. I think that would just move the bugs from the code into the proof definition. Your code may do what the proof says, but how do you know what the proof says is what you actually want to happen?

A formal spec isn't just ordinary source-code by another name, it's at a quite different level of abstraction, and (hopefully) it will be proven that its invariants always hold. (This is a separate step from proving that the model corresponds to the ultimate deliverable of the formal development process, be that source-code or binary.) Bugs in the formal spec aren't impossible, but use of formal methods doesn't preve…

> A formal spec isn't just ordinary source-code by another name, it's at a quite different level of abstraction

This is the fallacy people have when thinking they can "prove" anything useful with formal systems. Code is _already_ a kind formal specification of program behavior. For example `printf("Hello world");` is a specification of a program that prints hello world. And we already have an abundance of tooling for applying all kind of abstractions imaginable to code. Any success at "proving" correctness using formal methods can probably be transformed into a way to write programs that ensure correctness. For example, Rust has pretty much done so for a large class of bugs prevalent in C/C++.

The mathematician's wet dream of applying "mathematical proof" on computer code will not work. That said, the approach of inventing better abstractions and making it hard if not impossible for the programmer to write the wrong thing (as in Rust) is likely the way forward. I'd argue the Rust approach is in a very real way equivalent to a formal specification of program behavior that ensures the program does not have the various bugs that plagues C/C++.

Of course, as long as the programming language is Turing Complete you can't make it impossible for the programmer to mistakenly write something they didn't intend. No amount of formalism can prevent a programmer from writing `printf("hello word")` when they intended "hello world". Computers _already_ "do what I say", and "do what I mean" is impossible unless people invent a way for minds to telepathically transmit their intentions (by this point you'd have to wonder whether the intention is the conscious one or the subconscious ones).

Post reply on HN