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

Re: You are never taught how to build quality software

#381

Post by adastra22 » Sat, Dec 09, 2023, 7:53 AM UTC

AlphaWeaver wrote: post #350

foobiekr wrote: post #325

Earlier quoted context omitted.

For years a friend tried to get his department (where he worked as a lecturer) to add a software engineering course where the basic syllabus was to (1) receive a TOI from the last semester and the code base, (2) implement some new features in the code base, (3) deploy and operate the code for awhile, and (4) produce a TOI for the next semester. The code base was for a simple service that basically provided virus/malw…

In my university, (US, state school,) we had a software engineering course exactly like this. It was great in theory, but in practice, the experience was rushed, the codebase was poor quality, (layers upon layers of nothing features with varying code quality,) and the background knowledge was completely ignored. The application we had to work on was a Tomcat Java Web application with an Angular frontend, when neither…

That sounds like a very realistic classroom experience. I think you missed the point?

Re: You are never taught how to build quality software

#382

Post by mikeyouse » Sat, Dec 09, 2023, 7:58 AM UTC

ungamedplayer wrote: post #376

titzer wrote: post #173

Earlier quoted context omitted.

If you're specifically referring to CMU's compilers course, feel free to follow up with me offline.

Why does this feel like the professor trying to either fix the problem or give detention.

Lol this is who asked whether it was at CMU - https://s3d.cmu.edu/people/core-faculty/titzer-ben.html HN is such a great community.

Re: You are never taught how to build quality software

#383

Post by slvng » Sat, Dec 09, 2023, 7:59 AM UTC

CyberDildonics wrote: post #346

anacrolix wrote: post #342

Earlier quoted context omitted.

Someone's butthurt about never working for a company with a recognisable name?

How did you get to that? I can't even figure out what the comment I replied to is talking about. It isn't made up of full sentences and real words.

Not well written but understood the same.

Re: You are never taught how to build quality software

#384

Post by gorgoiler » Sat, Dec 09, 2023, 8:08 AM UTC

This is a bit more abstract than the article but in my experience the best software comes from people with taste, rigour, reasoning, a good vocabulary, strong principles, and the ability to write clear and concise English (or whatever human language is used in their team.)

When you truly understand the software you are writing then, and only then, can you communicate it logically in code for the computer to execute and, much more importantly, code for a person to read. Well written and well understood code means it’s very obvious what you are doing. Later, when the code has a bug or needs to be rewritten, then it will at least be clear what you were trying to do so that it can be fixed or extended in some way.

So then the question is how do we train people to have these skills? In school, science experiments are a good way to teach logical reasoning and communication — here is what I thought would happen, here is what I did, here is what happened, and here is what it means. Math teaches you how to reason abstractly and, again, prove your point with logic. It’s a slightly different beast in that it’s harder for a math experiment to go wrong. It’s also harder to come up with and overcome novel scenarios in the lab with math, so in all it complements science well. And of course reading and writing English build your ability to express your thoughts with words and sentences. Many other high school subjects combine these in various measures — history for example is data gathering, fuzzy logical deduction, and reasoning in written language.

The bottom line is that quality software starts by working with well educated people and conversely all the most abhorrent heaps of over coupled illegible nonsense I’ve seen has come from people who, to be blunt, just ain’t that smart or well rounded, intellectually.

It’s a principle I carry over to hiring: smart and well educated wins out over pure-smarts.

Re: You are never taught how to build quality software

#385

Post by CipherThrowaway » Sat, Dec 09, 2023, 8:22 AM UTC

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…

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

Cryptography and parsers simply do not belong in the same sentence. There is never a time when it is a appropriate to write your own cryptography. OTOH, most large compiler and interpreter projects have handwritten parsers, and many of them have handwritten lexers too.

Writing a parser can be simple enough to fit into a take-home assignment, and hand-written parser code ends up looking pretty similar to an LL grammar anyway. Parsing is also the easiest part of writing compiler or language tooling, so if a hand-written parser is too high a bar for the team then the entire project might questionable.

I'm not saying never use a parser generator, but I would personally prefer to work on a project with a well tested hand-written parser than a project using a parser generator. Especially if it complicates the build process with extra tooling, or is something really dated like Bison or ANTLR.

Re: You are never taught how to build quality software

#386

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

CipherThrowaway wrote: post #385

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…

> 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. Cryptography and parsers simply do not belong in the same sentence. There is never a time when it is a appropriate to write your own cryptography. OTOH, most large compiler and interpreter projects hav…

What’s dated about ANTLR?

Re: You are never taught how to build quality software

#387

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

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.

Well, if your product is on the hello world complexity, you might make it bug-free by just yourself simply through chance.

Formal proving doesn’t really scale much further, definitely not to “enterprise” product scale.

Re: You are never taught how to build quality software

#388

Post by valenterry » Sat, Dec 09, 2023, 8:29 AM UTC

foobiekr wrote: post #324

ttymck wrote: post #310

Earlier quoted context omitted.

I think the prevailing problem is that quality software often doesn't outperform shit software in terms of revenue, right?

It's not that, it's that quality doesn't matter and mostly neither does technology. If you are doing network switches or GPUs or server CPUs or whatever, yeah, technology matters. If you are building pretty much any SaaS, MCCA, etc. the tech is literally irrelevant and mostly the more "new" tech you use the worse off you are. Quality also only matters in some contexts and those are even rarer than the above. Timing a…

That's not true at all. Very often I've seen features being delayed or completely disregarded due to technology decisions.

It then looks like it was a "business reason" in the end, but it's not so easy to just distinguish what the root cause really was.

Re: You are never taught how to build quality software

#389

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

rocqua wrote: post #367

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.

I think with formal analysis, whole bug classes can be eliminated. Add to that a rigorous programming style, and 'bug-free' code is within reach. There will remain bugss that make it through, but they will be rare, and will need a chain of mistakes. Currently ways of coding to this kind of standard exist. But they are stupid. It involves things like no dynamic memory allocation, only fixed length for-loops, and other…

What seems to yield much better results is to have the program be built by two separate teams to a standard. Then both programs can be run simultaneously, checking each others output — I believe something like this is actually used in the aerospace industry.

Re: You are never taught how to build quality software

#390

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

datadeft wrote: post #90

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.

Spicy take on engineering. Why do we accept this for software when do not accept the same in other engineering domains?

Because complexity is boundless and in software it has no cost.

Building a house will have a restrictive initial budget for complexity, you don’t have enough in that budget for rotating floors, or an elevator that is catapulted to the correct floor, etc. These would cost both at engineering time and implementation time a huge amount. Less complexity is easier to analyze.

In case of software, complexity has negligible cost, relative to physical systems. You can increase it ad infinity — but proving it (the whole stack - from the hardware-OS-userspace software) correct is likely impossible with even the whole of mathematics, in certain cases.