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

211–220 of 500 posts

Re: You are never taught how to build quality software

#211

Post by HeyLaughingBoy »

KeplerBoy wrote: post #18

> It will be necessary to deliver software without bugs in time. Seems like a pretty bad premise to start an article on quality software. If you believe you can ship bug free code, it's time to switch careers.

Nothing is bug free.

Not buildings, not bridges, not cars, not airplanes, not software. There are mistakes in every field of engineering and the best we can hope for is to minimize them as much as possible.

Engineering is knowing (among other things) how to categorize the potential mistakes, develop procedures to reduce the chance of them being made and in the case that some slip through (and they will), estimate their impact and decide when you're "good enough."

Software engineering is no different.

Re: You are never taught how to build quality software

#212

Post by withinboredom »

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.

Usually, the hard way.

I've worked on so many poor-quality projects. I've had so many heated conversations trying to teach people that there are no such things as rules in SE and it's important to _know when to bend/break the rules_. Rigorously following rules doesn't mean high quality, automatically. Some things simply don't exist in the little world you're building.

Translations, for example, usually live outside of any layered cake you are making. If you write a string that will be shown to a user deep down in your code, it needs to be marked for translation and translated. If you try to layer it ... gods help anyone who comes along to change that switch statement.

There are lots of other cross-cutting concerns that people try to put into a box because of "rules" that don't belong in a box. That's usually where your quality starts to plummet.

Re: You are never taught how to build quality software

#213

Post by fidotron »

bluGill wrote: post #185
fidotron wrote: post #144

Earlier quoted context omitted.

If it works within specs it is bug free. It doesn’t matter how it is made if it works within specs, which is one of the real unfortunate truths of software. The other is working out the correct specification is far harder than coding is. For example it is trivial to write a bug free program that multiplies an integer between 3 and 45 by two.

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.

Re: You are never taught how to build quality software

#214

Post by ponector »

fidotron wrote: post #112
sanderjd wrote: post #92

Earlier quoted context omitted.

What proof is all around us?

The amount of software in everyday objects which runs without exhibiting bugs to such a degree we do not notice most of it even exists.

I encounter bugs everywhere all time. List goes very long.

Microwave has random errors from time to time.

Robo vacuum freezes.

Parking meter malfunction.

Public transport ticket machine don't want to give me a ticket.

Online banking failing to make a transfer because I use UI with other language.

Mobile banking failing to make a transfer because I use not native currency.

Car has issues as well, incorrect fuel amount is injected by computer.

Online pages have tons of bugs, many are barely usable.

Re: You are never taught how to build quality software

#215

Post by petsfed »

__loam wrote: post #149
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…

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 diagrams in their careers, and will almost certainly deal with fussy micromanagers who demand their flow diagrams adhere to some arbitrary schema that has only limited impact on the actual quality of their work or documentation.

UML is complete, at least.

Re: You are never taught how to build quality software

#216

Post by bluGill »

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 verification worth the time and effort? There is a lot places where we as an industry have ideas but are in heated debates without knowing how to find a truth.

Re: You are never taught how to build quality software

#217

Post by m0llusk »

This is a side issue, but it seems to me like this general problem is what is making strict typing so popular. If there were tests and documentation in place and parameters were being checked then strict typing wouldn't have much benefit because types are just one aspect of making sure the whole system is working as intended. Instead in many cases development is chaos with little if any documentation and testing and strict typing is great because it is the only tie holding the bundle of sticks together.

Re: You are never taught how to build quality software

#218

Post by ChuckMcM »

From the article -- At some point, I realized that I wasn't using the right arguments either. Explaining that the software will be 'more stable' or 'make maintenance much easier' is not palpable for someone who doesn't work in the codebase themselves. We need to speak about money. As developers, we need to speak about the cost of not doing QA. This is the language of business and managers in general.

The more general way of saying this is, "If you need someone's approval to do something, explain it as a good idea for them." Took me a bit to learn this in engineering, you would think "but it will be correct!" would be an unassailable argument but as the author notes, the person who has to sign off on it may not care if it is correct, even if you passionately do care. This works for everything at the job, not just fixing software correctly.

Re: You are never taught how to build quality software

#219

Post by withinboredom »

ck45 wrote: post #194

This has been previously handled in the excellent book "The Problem with Software - Why Smart Engineers Write Bad Code" by Adam Barr ( https://mitpress.mit.edu/9780262038515/the-problem-with-soft... )

I literally can't figure out how to buy the book from that site. I clicked ebook, then amazon, and the link is dead. You should probably just share a working link.

Re: You are never taught how to build quality software

#220

Post by bluGill »

WJW wrote: post #180
Syntonicles wrote: post #76

Earlier quoted context omitted.

Will you please elaborate?

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%?)
Post reply on HN