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

251–260 of 500 posts

Re: You are never taught how to build quality software

#251

Post by MaxBarraclough »

xmprt wrote: post #227
MaxBarraclough wrote: post #206

Earlier quoted context omitted.

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…

I think the reason that formal proofs haven't really caught on is because it's just adding more complexity and stuff to maintain. The list of things that need to be maintained just keeps growing: code, tests, deployment tooling, configs, environments, etc. And now add a formal proof onto that. If the user changes their requirements then the proof needs to change. A lot of code changes will probably necessitate a proo…

> more complexity and stuff to maintain

Yes, with the current state of the art, adopting formal methods means adopting a radically different approach to software development. For 'rapid application development' work, it isn't going to be a good choice. It's only a real consideration if you're serious about developing ultra-low-defect software (to use a term from the AdaCore folks).

> it doesn't even eliminate bugs because the formal proof could include a bug too

This is rather dismissive. Formal methods have been successfully used in various life-critical software systems, such as medical equipment and avionics.

As I said above, formal methods can eliminate all 'runtime errors' (like out-of-bounds array access), and there's a lot of power in formally guaranteeing that the model's invariants are never broken.

> I suppose it could help in trivial cases like sanity checking that a value isn't null or that a lock is only held by a single thread

No, this doesn't accurately reflect how formal methods work. I suggest taking a look at the PDFs I linked above. For one thing, formal modelling is not done using a programming language.

Re: You are never taught how to build quality software

#252

Post by ponector »

codenesium wrote: post #229

I ask how do you build quality software in interviews. A lot of people are caught completely flat footed by it. They have no idea.

What if they ask you: and you? Are you actually building high quality software?

What are your quality gates? How many open bugs are there on production? How often you close bugs with resolution: won't fix(because of budget issues)? How often do you have production incidents? What is your testing strategy? How are you testing your requirements before assigning them to the developer for implementation? Do you hire external professionals for security testing?

Re: You are never taught how to build quality software

#253

Post by sanderjd »

duped wrote: post #139
sanderjd wrote: post #104

Earlier quoted context omitted.

> and doesn't pretend to be I'm not sure about this part... A very common pattern in my conversations with working class friends and family from my parents' generation is: "we were told that if we sent our kids to college, they'd have better lives than we did, but instead we all just ended up with more debt than we could handle". It's tricky! If you tell teenagers and their parents the truth - this purely academic pr…

> I'm not sure about this part... If you want to know what a university will teach your kids, ask them. They'll even tell you without asking them - it was pretty obvious to me as a dumb high school kid on campus visits what the emphasis of one program or another was going to be.

What I'm saying is: universities are incentivized to mislead people (including themselves!) about this.

If you are a working class family with a kid who is very talented at math, and you go sit down with the counselors and ask them: If my child studies pure theoretical math, will that open them up to a life full of possibilities? they will say "yes, it absolutely will". But that's not true. It might be true, but it's a big risk. It's a risk a wealthy family can very easily absorb. But if this child from this working class family takes on this risk using student debt, it might go poorly. They might very well be good at pure math but not be good enough to go into academia. Then they might be unsure what else they can do with that degree, unable to get their foot in the door at the kinds of employers where just a general proof-of-being-smart degree is enough. And now they have debt and uncertainty about what to do.

It also might work out great! But it's a risk. And I know a number of people who feel they ended up on the wrong side of that risk.

Re: You are never taught how to build quality software

#254

Post by failbuffer »

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

A whiteboard is complete. Every other way of diagramming software is deficient. Change my mind. ;-)

Re: You are never taught how to build quality software

#255

Post by 3abiton »

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?

Re: You are never taught how to build quality software

#256

Post by ch4s3 »

t43562 wrote: post #224

The reason I find it easier to work with people who have a degree in Computer Science is that I don't have to convince them of the need for good algorithms and not to try to implement parsers or cryptography by hand. When it comes to software engineering I feel there is no qualification where you can feel that the gross naivety about quality and working in teams (and with other teams) has been similarly ironed out. I…

Hum, interesting perspective. I did 95% of a masters in CS before leaving to do a startup and while I can see the value of parser generators, there are a LOT of times when it is appropriate, useful, and more performant to write your own simple parser. It's often in my opinion the right thing to to first for simple cases. Clearly you should test it and consider functional requirements, but a stringy protocol with clear delimiters is usually dead simple to parse and depending on your use case you can focus on a subset. If you're writing a language... my advice might be different.

Re: You are never taught how to build quality software

#257

Post by Kamq »

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

> 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 mean, yeah. Seeing that wave happen over the course of their college career would probably be better prep for a career than most CS classes.

Re: You are never taught how to build quality software

#258

Post by radicalcentrist »

Gare wrote: post #108
codegeek wrote: post #87

Earlier quoted context omitted.

Yep. If you have written production grade software at real companies, you know that the moment you make that new commit (even if 1 liner change), you are now ready to accept that it could break something. yes you can do your unit tests, integration test, User Acceptance Tests and what not. But every code change = new possible bug that you may not be able to catch until it occurs to a customer. Whenever I hear a devel…

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.

To quote Donald Knuth, "Beware of bugs in the above code; I have only proved it correct, not tried it."

Re: You are never taught how to build quality software

#259

Post by dudul »

> What uni Teaches You > blablabla

So I'm gonna need to see dome data here. How many universities has this guy surveyed to make a claim like that?

My university did teach me design patterns, architecture and all. My professors did give me projects where requirements would change mid way and the software had to adapt without being completely rewritten. They did teache to write unit tests, to use a build tool to generate docs, reports, etc.

Was I battle tested for my first job? No, but it really wasn't as bad as what's described here.

Re: You are never taught how to build quality software

#260

Post by kevindamm »

Verdex wrote: post #250
kevindamm wrote: post #200

Earlier quoted context omitted.

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.

Fair enough, I was being annoyingly pedantic.

[I believe that] it's important to get attribution correct.

Post reply on HN