You are never taught how to build quality software • Hacker News Board

Re: You are never taught how to build quality software

#391

Post by kaba0 » Sat, Dec 09, 2023, 8:48 AM UTC

ska wrote: post #245

KeplerBoy wrote: post #225

Earlier quoted context omitted.

> 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 dynamic…

> 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.

Even with all of those applied, we wouldn’t be magically better. Complexity is simply unbounded. It’s almost impossible to reason about parallel code with shared mutable state.

Re: You are never taught how to build quality software

#392

Post by toolslive » Sat, Dec 09, 2023, 8:48 AM UTC

virgilp wrote: post #373

sdiupIGPWEfh wrote: post #359

Earlier quoted context omitted.

> strict cheating policies that essentially made any group work verboten If I had to guess, some polytechnic school or another? With some classes even forbidding discussing work with other students, where each assignment required a signed (digitally or otherwise) affidavit listing everyone you consulted, acknowledging that if you actually listed anyone, you were admitting to violating the academic honesty policies an…

I taught a course "in a previous life" and while I wasn't anything close to as strict as you say here, I can tell you the flip side: students would copy, modify superficially (some, less superficially) and then claim "it's my work, we just talked, that's why the similarities!" (with some even having the nerve to say, "it's not copied, look, plagiarism detection software says similarity is less than x%!) Perhaps I was…

What we did when correcting the homework is compare the signature of the assembly output (not manually of course). You can move functions around, rename them, change the names of variables, .... but the signature of the instructions remains the same.

We caught 2 guys, of course we didn't know who copied from whom, but we quickly found out by challenging each of them with a fizz-buzz kind of question.

Re: You are never taught how to build quality software

#393

Post by maximus-decimus » Sat, Dec 09, 2023, 9:09 AM UTC

bluGill wrote: post #210

johnnyanmac wrote: post #145

> Neglecting QA is a shame because 90%+ of all students work in a company context after they finish their degrees. It will be necessary to deliver software without bugs in time. once again bringing up the hot debate of "are colleges job prep or research institutions"? Many students these days will proceed to grab a job, but is that something a university should strive to be? I wish at the bare minimum there were more…

> is that something a university should strive to be? Universities taking public money (including students government grants/loans) should strive to make society better. Part of that is getting kids into good jobs that society needs done. There are a few "retired" people taking classes that they are paying for on their own just for fun. If those people think they are getting value despite taking subjects society does…

People making roads and building powerplants also take government money. Do you expect them to prepare people for software dev jobs too?

Just because companies decided to start requiring degrees because they're too stuff to pay their own staff, IMO they shouldn't get to divert universities from their original mission, which is education and research. Afterall, those are also important to society, and if they don't do it, who will?

Re: You are never taught how to build quality software

#394

Post by globular-toast » Sat, Dec 09, 2023, 9:12 AM UTC

randomdata wrote: post #2

Is there any human activity where quality is an attribute successfully taught? In my experience, being able to produce something of quality is gained only through practice, practice, practice.

Practice only matters if you try to produce quality. If you just practice producing crap you'll only get good at producing crap. But I suppose if someone doesn't care about quality (and these people do exist) all bets are off really.

Re: You are never taught how to build quality software

#395

Post by kaba0 » Sat, Dec 09, 2023, 9:40 AM UTC

bee_rider wrote: post #96

KeplerBoy wrote: post #46

Earlier quoted context omitted.

I'm not sure about that. Which engineering domain do you have in mind? Maybe show-stopping bugs are somewhat unique to software engineering, but all somewhat-complex products are flawed to some extent imho. It might be an unergonomic handle on a frying pan, furniture that visibly warps under the slightest load (looking at ikea shelfing) or the lettering coming off the frequently used buttons on a coffee machine.

But there do exist shelves that don’t warp, when used within some reasonable bounds. I’d also quibble about the buttons on the coffee machine. They might be properly designed, just subject to the normal wear-and-tear that is inevitable in the real world. This is not a defect, physical devices have finite lifespans. As far as computers go… if we got to the point where the main thing that killed our programs was the ha…

A shelve is a dumb primitive static object though. Even a simple hello world goes over a huge amount of lines of code before it is displayed on a screen, ANY one of which being faulty could result in a bug visible to the enduser. And most of that is not even controlled by the programmer — they might call into libc, which calls into the OS, which calls into drawing/font rendering libraries, that calls into video card drivers that “calls” into the screen’s firmware.

And this is almost the simplest possible program.

Re: You are never taught how to build quality software

#396

Post by master-lincoln » Sat, Dec 09, 2023, 9:59 AM UTC

failbuffer wrote: post #254

petsfed wrote: post #215

Earlier quoted context omitted.

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. ;-)

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 prepared that nobody will completely understand your diagram without explanation

Re: You are never taught how to build quality software

#397

Post by denton-scratch » Sat, Dec 09, 2023, 10:04 AM UTC

sdiupIGPWEfh wrote: post #359

steveBK123 wrote: post #338

Earlier quoted context omitted.

Almost every CS course I took went the other way and had strict cheating policies that essentially made any group work verboten. There was 1 group project in 1 course I took in 4 years. My spouse on the other hand took an explicitly IT program and they had group projects, engaging with real world users, building real solutions, etc.

> strict cheating policies that essentially made any group work verboten If I had to guess, some polytechnic school or another? With some classes even forbidding discussing work with other students, where each assignment required a signed (digitally or otherwise) affidavit listing everyone you consulted, acknowledging that if you actually listed anyone, you were admitting to violating the academic honesty policies an…

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 a problem with giving the same mark to each member of a group of collaborators. You just have to test that each individual can explain what they've submitted.

Re: You are never taught how to build quality software

#398

Post by [deleted] » Sat, Dec 09, 2023, 10:12 AM UTC

Verdex wrote: post #172

akhosravian wrote: post #137

Earlier quoted context omitted.

I’m not a CS academic or a mathematician, but don’t Godel’s incompleteness theorems preclude a formal proof of correctness?

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).

[deleted]

Re: You are never taught how to build quality software

#399

Post by prendino » Sat, Dec 09, 2023, 10:15 AM UTC

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…

We were taught these things at the Bachelor's program in CS I went to in Sweden. At my first job I then slipped on a banana peel into a de facto tech lead position within a year, and I don't think it was due to my inherent greatness but rather that I was taught software engineering and the other colleagues at my level had not.

Ironically, the software engineering courses were the only ones I disliked while a student. An entire course in design patterns where strict adherence to UML was enforced felt a bit archaic. We had a course in software QA which mostly consisted of learning TDD and the standard tooling in the Java ecosystem, with some cursory walkthroughs of other types of QA like static analysis, fuzzing and performance testing. At the time it felt so boring, I liked to actually build stuff! A couple of years later I joined a team with very competent, CS-educated developers tasked to set up a workflow and all the tooling for testing software with high security requirements. They were dumbfounded when I knew what all the stuff they were tasked to do was!

Re: You are never taught how to build quality software

#400

Post by MaxBarraclough » Sat, Dec 09, 2023, 10:44 AM UTC

Dalewyn wrote: post #275

MaxBarraclough wrote: post #119

Earlier quoted context omitted.

That's backward. A successful software development methodology will tend to catch bugs early in the development pipeline. The doesn't know how to fix bugs idea seems pretty silly.

I think you misunderstand, I'm talking about a programmer who makes perfect, bug-free code in one shot. There are no bugs to catch and fix, because this "perfect" programmer never writes buggy code. The moral of the sayings is, that "perfect" programmer is actually a bad programmer because he wouldn't know how to fix bugs by virtue of never needing to deal with them. To reuse the driver analogy, the driver who never…

I don't see that I misunderstood anything.

If a software developer consistently delivers high-quality software on time and on budget, that means they're good at their job, pretty much by definition. It would make no sense to infer they're bad at fixing bugs.

It would make sense to infer instead that they're good at catching and fixing bugs prior to release, which is what we want from a software development process.

> the driver who never misses a turn is a bad driver because he doesn't know what to do when he does miss a turn

Missing a turn during a driving test will never improve your odds of passing.

The driver who never misses a turn presumably has excellent awareness and will be well equipped to deal with a mistake should they make one. They also probably got that way by missing plenty of turns when they were less experienced.