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

241–250 of 500 posts

Re: You are never taught how to build quality software

#241

Post by MaxBarraclough »

bluGill wrote: post #220
WJW wrote: post #180

Earlier quoted context omitted.

Aviation in particular has a very strong culture around (government mandated) checklists and post-crash investigations. This has both pros and cons. The pros is that every airline learns from the mistakes made by every other airline and over time the system becomes really quite safe indeed. The cons are that it is quite expensive and time consuming. Imagine if every software company was obliged by law to: - Every sin…

I wish someone would create that 500 line checklist. I've seem attempts, but they tend to be either not actionable (is the software high quality - meaningless), or of metrics that are just gamed (is test code coverage > 80%?)

Not quite what you're asking for, but the Joint Strike Fighter C++ Coding Standards document is freely available. [0] It's 141 pages.

It's specific to the complex and unsafe C++ language though, rather than addressing broader software development methodology.

[0] [PDF] https://www.stroustrup.com/JSF-AV-rules.pdf

Re: You are never taught how to build quality software

#242

Post by ponector »

tanepiper wrote: post #196

Maybe a spicy take (FWIW I'm also self-taught) Software engineering quality isn't something you teach, it's something you learn.

It is the same as you learn about backup and restore process. And then you learn hard way that you should have been testing your backups, if they can be used to restore data.

Re: You are never taught how to build quality software

#243

Post by satisfice »

Verdex wrote: post #4
ysofunny wrote: post #3

you cannot be taught what nobody knows how to do or maybe, them who know how to do this are just unable to spread this knowledge... something about how they think their private secret codes are the source of their wealth when in fact, it's merely the scheme by which they mantain an advantageous capacity to extract energy from them seeking to learn how to build quality software

This is what I came here for. There's an obvious comprehensibility complexity to code to anyone who has spent almost any time what so ever trying to make something happen in software. However, we've got zero academics or theory around it. Just 'best practices' (ie a thing other people are known to do so if things go wrong we can deflect blame). And code smells (ie the code makes your tummy feel bad. yay objective mea…

The scientific groundwork for excellent testing, anyway, has already been done-- but not in the realm of computer science. This is because computer scientists are singularly ill equipped to study what computer scientists do. In other words, if you want to understand testing, you have to watch testers at work, and that is social science research. CS does not take social science seriously.

An example of such research done well can be found in Exploring Science, by Klahr. The author and his colleagues look very closely at how people interact with a system and experiment with it, leading to wonderful insights about testing processes. I've incorporated those lessons into my classes on software testing, for instance.

Re: You are never taught how to build quality software

#244

Post by rcbdev »

In the Austria these topics are usually researched at universities of applied sciences (Fachhochschule) rather than universities (Universität). Some technical universities here attempt to combine these disciplines, to moderate success.

For example, the largest technical UAS in Austria offers Computer Science as an undergrad degree but only does research on Software Engineering at a graduate level.

Re: You are never taught how to build quality software

#245

Post by ska »

KeplerBoy wrote: post #225
ska wrote: post #106

Earlier quoted context omitted.

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…

> One is that we don't understand the fundamentals of software as well as the underpinnings of other engineering disciplines. That sounds like an awfully bold claim. I have the feeling we understand software a lot better than we understand mechanical engineering (and by extension material sciences) or fluid dynamics. By a big margin. I worked with finite element software and with CFD solvers, you wouldn't believe how…

> That sounds like an awfully bold claim.

To the contrary, it's nearly canonical. Most of the problems pointed out in the 70s (mythical man month) have still not been resolved, 50 years later.

>you wouldn't believe how hard it

Oh, I'd believe it (I've designed and built similar things, and had colleagues in CFD).

But you are definitely cherry picking here. The problem with CFD is we don't understand the fluid dynamics part very well; turbulence is a big unsolved problem still, though we have been generating better techniques. This is so true that in an undergraduate physics degree, there is usually a point where they say something like: "now that you think you know how lots of things work, let's introduce turbulence"

But a lot of mechanical engineering and the underlying physics and materials science is actually pretty well understood, to the degree that we can be much more predictive about the trade offs than typically is possible in software. Same goes for electrical, civil, and chem. Each of them have areas of fuzziness, but also a pretty solid core.

Re: You are never taught how to build quality software

#246

Post by ponector »

bluGill wrote: post #216
sanderjd wrote: post #129

I have been, at various points in time, taught how to build quality software. I think the large majority of people I work with have been taught about this as well. So I'm not sure who the "you are never taught ..." is referring to here. Should it perhaps instead be "I was never taught ..."?

Were you really taught that, or were you taught cargo-cult things that don't make for quality software. I've had some of each in my past. This is a big area that I wish researchers would focus on. What really does make for long term high quality software. What are the actual trade offs. How do we mitigate them. What are the limits to TDD - is it good? Detroit or London mocks - when to use each? When is formal verific…

My colleague, a senior full stack developer with CS masters degree has been asking: "why should I write tests if I can write new features?" And that is what managers often think. Because you can present new features to business but can't do the same with tests. They have no immediate value.

Re: You are never taught how to build quality software

#247

Post by aschearer »

Verdex wrote: post #4
ysofunny wrote: post #3

you cannot be taught what nobody knows how to do or maybe, them who know how to do this are just unable to spread this knowledge... something about how they think their private secret codes are the source of their wealth when in fact, it's merely the scheme by which they mantain an advantageous capacity to extract energy from them seeking to learn how to build quality software

This is what I came here for. There's an obvious comprehensibility complexity to code to anyone who has spent almost any time what so ever trying to make something happen in software. However, we've got zero academics or theory around it. Just 'best practices' (ie a thing other people are known to do so if things go wrong we can deflect blame). And code smells (ie the code makes your tummy feel bad. yay objective mea…

I found these thought provoking:

The Power of 10: Rules for Developing Safety-Critical Code[1]

Assessing the Relationship between Software Assertions and Code Quality: An Empirical Investigation[2]

Cyclomatic Complexity and Basis Path Testing Study[3]

[1]: https://web.eecs.umich.edu/~imarkov/10rules.pdf

[2]: https://www.microsoft.com/en-us/research/wp-content/uploads/...

[3]: https://ntrs.nasa.gov/api/citations/20205011566/downloads/20...

Re: You are never taught how to build quality software

#248

Post by sanderjd »

bluGill wrote: post #216
sanderjd wrote: post #129

I have been, at various points in time, taught how to build quality software. I think the large majority of people I work with have been taught about this as well. So I'm not sure who the "you are never taught ..." is referring to here. Should it perhaps instead be "I was never taught ..."?

Were you really taught that, or were you taught cargo-cult things that don't make for quality software. I've had some of each in my past. This is a big area that I wish researchers would focus on. What really does make for long term high quality software. What are the actual trade offs. How do we mitigate them. What are the limits to TDD - is it good? Detroit or London mocks - when to use each? When is formal verific…

No, I have been, at various times, taught about a number of different techniques that are used in the endeavor to build quality software, along with lots of discussion about the tradeoffs between them and when they may be more or less appropriate.

It certainly is not something with a single easy answer, and I certainly agree that it remains a fruitful thing to continue researching, but that doesn't mean that there is nothing to be taught about it. There is lots to be taught about this, and lots that is taught about it, to lots of people.

Re: You are never taught how to build quality software

#250

Post by Verdex »

kevindamm wrote: post #200
Verdex wrote: post #172

Earlier quoted context omitted.

No. Godel means that we can't have an algorithmic box that we put a program into and out comes a true/false statement of halting. Nothing is stopping you from writing the proof manually for each program that you want to prove properties for. ALSO, you can write sub-turing complete programs. Those are allowed to have automated halting proofs (see idris et al).

What you're talking about is actually the Church-Turing thesis and the halting problem. While, yes, computability and provability are very closely related, it's important to get attribution correct. More details on what Gödel's Incompleteness Theorem really said are in a sibling comment so I won't repeat them here.

> it's important to get attribution correct.

Really? Says who?

Or perhaps you'll prove it from first principles. Although if turns out to be difficult, that's okay. Somebody mentioned something about systems being either complete or consistent but never both. Some things can be true but not proveably so. Can't quite remember who it was though.

Post reply on HN