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

451–460 of 500 posts

Re: You are never taught how to build quality software

#451

Post by denton-scratch »

steveBK123 wrote: post #425
denton-scratch wrote: post #397

Earlier quoted context omitted.

I had students that copied one-another's work; in fact I had few students that didn't copy. It made it impossible to mark their projects correctly, so I asked my more-experienced colleagues. The best advice I got was to explain the difference between collaboration (strongly encouraged) and plagiarism (re-take the course if you're lucky). Forbidding collaboration is a disastrous policy, so an instructor shouldn't have…

My school auto-graded everything (file drop your code to a server by midnight & get a score back). I don't recall a single instance of TA/professor written or verbal feedback on code.

Yuh. I guess that's "modern times". I taught in the late eighties, and auto-grading wasn't a thing.

FWIW, I was a "temporary visiting lecturer", i.e. contract fill-in help. I had to write the syllabus (literally), the course plan, and the hand-outs. I also had to write all the tests and the exams; and I had to mark the exams, and then sit on the exam board through the summer holidays. The pretty girls would flutter their eyelashes at me, and ask for leniency. I suspect they took their cue from my louche colleague, who was evidently happy to take sexual advantage of his students in exchange for better marks.

[Edit] I liked this colleague; but I would not have introduced him to my wife or my daughter.

Re: You are never taught how to build quality software

#452

Post by fidotron »

sanderjd wrote: post #450
fidotron wrote: post #213

Earlier quoted context omitted.

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.

Yes, but that's not real software.

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

Re: You are never taught how to build quality software

#453

Post by HeyLaughingBoy »

sheepshear wrote: post #273
ska wrote: post #221

Earlier quoted context omitted.

What I'm saying is that if your goal is to introduce more engineering rigor and your plan is for for the tiny percentage of graduate school graduates to percolate these ideas through the industry, it's probably a bad plan and likely to fail. This was a thread about why software developers don't do engineering like other disciplines. One partial answer is that those other disciplines take it much more seriously at the…

> Probably the more compelling answer is that the industry doesn't' really want them to for the most part. This is it. Everyone is making money hand over fist despite not doing it. You might want it, but you don't need it.

Sad but true.

Re: You are never taught how to build quality software

#454

Post by fidotron »

sanderjd wrote: post #442
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.

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. Failing to do that is mainly a great way for certain software management structures to manipulate people by ensuring everything is negotiable all the time, and has the side effect that no one can even say if something is a bug or not. (And this pattern is very clear in the discussion in this thread - there is a definite unwillingness to define what a bug is).

IME the process of automated fuzzing radically improves all round quality simply because it shakes out so many of the implicit assumptions and forces you specify the exact expected results. The simple truth is most people are too lazy and/or lack the discipline needed to do it.

Re: You are never taught how to build quality software

#455

Post by steveBK123 »

denton-scratch wrote: post #451
steveBK123 wrote: post #425

Earlier quoted context omitted.

My school auto-graded everything (file drop your code to a server by midnight & get a score back). I don't recall a single instance of TA/professor written or verbal feedback on code.

Yuh. I guess that's "modern times". I taught in the late eighties, and auto-grading wasn't a thing. FWIW, I was a "temporary visiting lecturer", i.e. contract fill-in help. I had to write the syllabus (literally), the course plan, and the hand-outs. I also had to write all the tests and the exams; and I had to mark the exams, and then sit on the exam board through the summer holidays. The pretty girls would flutter t…

Yikes.

Actually not so modern, my college was auto-grading 20 years ago.

Re: You are never taught how to build quality software

#456

Post by tylerchurch »

codegeek wrote: post #261
wvenable wrote: post #198

Earlier quoted context omitted.

It's always amazing when I get a bug report from a product that's been running bug free in production for years with minimal changes but some user did some combination of things that had never been done and it blows up. Usually it's something extremely simple to fix too.

This happens a lot more than one may think especially with products that have lot of features. Some features are used sparingly and the moment a customer uses that feature a bit more in depth, boom. Something is broken.

> especially with products that have lot of features

No kidding. I'm 2 or 3 years into working on a SaaS app started in ~2013 and I still get bug reports from users that make me say "what!? we have that feature!?"

Re: You are never taught how to build quality software

#457

Post by ChrisMarshallNY »

tmshu1 wrote: post #416
ChrisMarshallNY wrote: post #409

I really liked the umbrella demo :) Here's my take on testing[0]. I write Quality software. It's a matter of personal satisfaction. Many folks can't really tell the difference between relatively good software, and very high Quality software, but the cost difference can be quite large. We don't get rich, writing top-shelf software. The issue is, in my opinion, that we don't even produce much "relatively good" software…

Thank you for sharing. I just read through several of your blog posts and especially resonate with your “evolutionary design”. The idea of integration tests/test harness first over unit tests makes a lot of sense to me too. As a one person team myself, the “art” of creating quality software products, at speed, is revealing itself and is quite fascinating. It’s not everyday that devs like me get to learn from someone…

Aw, shucks, thanks.

But I am quite aware that I have a ton more to learn, and places like this, are a good place to do that.

I should get around to doing some more writing, though. I've been very involved in a project, for the last couple of years, and haven't taken the time to write.

Now that the project is approaching release, I may be able to free up some time.

Re: You are never taught how to build quality software

#458

Post by OnlyMortal »

master-lincoln wrote: post #396
failbuffer wrote: post #254

Earlier quoted context omitted.

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

A whiteboard is just a medium to draw. Uml is a standard that says how to express certain ideas as symbols that can be drawn. It's not clear to me what your argument is. Is it using whiteboards to draw uml instead of special uml software? If so, be prepared to take much longer to draw the diagram. Or do you mean uml is deficient compared to free drawing of symbols on a whiteboard without a standard? If so, be prepare…

UML is just the common parlance so that we all understand what’s represented.

No need for a specific tool - unless you’re doing PowerPoint slides. Visio is good enough in that case if you have Windows.

Re: You are never taught how to build quality software

#459

Post by zamalek »

BobaFloutist wrote: post #64
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 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.

Re: You are never taught how to build quality software

#460

Post by elptacek »

skeeter2020 wrote: post #436
Mtinie wrote: post #365

Earlier quoted context omitted.

Am I understanding correctly that your concern was that the course is too close to reality to be useful?

You needed to partner with the business school to get a future MBA to convince the faculty (executives) the biggest return (profitability) was a total re-write!

I had a single phone interview with someone at Northwestern (a long time ago) where they were looking for someone to build a pen of developers to "partner" with MBA students to turn ideas into apps. I laughed so hard my sides hurt.
Post reply on HN