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

221–230 of 500 posts

Re: You are never taught how to build quality software

#221

Post by ska »

HeyLaughingBoy wrote: post #203
ska wrote: post #188

Earlier quoted context omitted.

To a first approximation, software developers don't have masters degrees. If you are thinking about changing how an industry does its work, focusing on graduate courses seems counterproductive.

I disagree. I have a Master's in Software Engineering and the way to change things is for those with the formal education to try and spread good practices as much as possible in the workplace. Sometimes the main benefit is just knowing that good practices exist so you can seek them out. The biggest impact I've had at the places I've worked have been about procedures and methodology, not how to use UML or draw a dataf…

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 undergraduate level, at least on average.

Probably the more compelling answer is that the industry doesn't' really want them to for the most part.

> but you'd be amazed at how even in 2023

I really wouldn't.

Re: You are never taught how to build quality software

#222

Post by ponector »

fidotron wrote: post #144
sanderjd wrote: post #124

Earlier quoted context omitted.

Yes, but that software is not bug-free. The claim was not "it's impossible to make software that does not exhibit bugs too a casually noticeable degree". People who know how the sausage is made will always know of a bunch of bugs that haven't been fixed exactly because they aren't impactful enough to be worth the effort required to fix them.

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.

You know, there could be bugs in spec. And you can have a software written with bugs but according to spec.

When testing should start? BEFORE the first line of code is written.

Re: You are never taught how to build quality software

#224

Post by t43562 »

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.

Instead you get people hardened in sin from their repeated experience of writing one horrible bit of untested code quickly and then leaving before the shit truly hit the fan :-)

One's management is very impressed with those kind of people and very contemptuous of those left behind who have to painstakingly clean up the mess.

Re: You are never taught how to build quality software

#225

Post by KeplerBoy »

ska wrote: post #106
datadeft wrote: post #90

Earlier quoted context omitted.

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

There are a few aspects. One is that we don't understand the fundamentals of software as well as the underpinnings of other engineering disciplines. More importantly though, for the most part we choose not to do engineering. By which I mean this - we know how to do this better, and we apply those techniques in areas where the consequences of failure are high. Aerospace, medical devices, etc. It differs a bit industry…

> 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 hard it is to simulate a proper airflow over a simple airfoil and get the same results as in the wind tunnel.

Re: You are never taught how to build quality software

#226

Post by ponector »

fidotron wrote: post #189
digging wrote: post #174

Earlier quoted context omitted.

> If it works within specs it is bug free. No, it's functional. If it has bugs, it's not bug-free. By definition.

What would it mean to be bug free then? To quote a former marketing guy “it should work out what the user intends to do and do it”?

Bug free software means developers would not disclose any information about present bugs in the software they ship to customers.

Really bug free commercial software does not exist. And can't exist. There are always bugs which are known but would not be fixed.

Re: You are never taught how to build quality software

#227

Post by xmprt »

MaxBarraclough wrote: post #206
cochne wrote: post #138

Earlier quoted context omitted.

I never really got how proofs are supposed to solve this issue. I think that would just move the bugs from the code into the proof definition. Your code may do what the proof says, but how do you know what the proof says is what you actually want to happen?

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 proof change as well. And it doesn't even eliminate bugs because the formal proof could include a bug too. 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 but it seems like a lot of those checks are already integrated in build tooling in one way or another.

Re: You are never taught how to build quality software

#228

Post by aidenn0 »

nikhil896 wrote: post #71
aidenn0 wrote: post #66

I wonder how much of the lack of QA is rational. That is to say, for most projects does shipping with lots of somewhat hard-to-find bugs actually hurt the bottom line? For some classes of bugs it can (e.g. if the software is so bad as to open you to a class-action lawsuit; in b2b software bugs that put you in breech of contract), but for many classes of consumer software, it's not clear to me that shipping software t…

It starts mattering more for consumer software when you reach mass scale. Somewhat hard-to-find bugs at the scale of hundreds of millions of users (like a social media company), turn into bugs faced by hundreds of thousands of users. But at that scale (in my experience), QA is up front and center and is typically a core pillar of engineering orgs.

> It starts mattering more for consumer software when you reach mass scale. Somewhat hard-to-find bugs at the scale of hundreds of millions of users (like a social media company), turn into bugs faced by hundreds of thousands of users.

From a cynical point of view, if those hundreds of thousands of users will use your product despite the bugs, does it matter?

Re: You are never taught how to build quality software

#230

Post by Communitivity »

There is a corollary. You need to learn how to build quality software. You also need to know what level of quality vs completeness tradeoff you need to make.

Imagine I have a deadline of Jan 15th to demo features x, y, and z to senior leadership (who then will make funding decisions that could impact my project), and I get to Jan 15th with x, y, and not z - or worse, none of them working fully. But the code quality is high, there are no TODOs hanging around, no extra development focused logging, no duplication of code, no leaky abstractions.

That is a 100% fail in leadership's eyes, unless you have a really good story on why z didn't get shipped (and code quality is NOT that).

All those things I listed will have to be addressed at some point, and the longer they go without being addressed the harder they will be to address. But if you need to do that to meet deadlines, then you do it.

Of course, if you are in a place where leadership allows you to work from a backlog and demonstrations and features to demo are scheduled not arbitrarily based on leadership's schedule/interest, but on the features that are newly shipped since the last demo, then you are in luck.

At the end of the day the important thing to remember is that you are not being paid to build software. You are being paid to provide a solution to your customer's problem. Other than CTOs and some forward thinking leaders, they don't care about the software. They care about whether the problem is solved, did it cost me more or less than expected in labor and materiel, and is it compliant with necessary laws/regulations.

Post reply on HN