Hacker News Reader

> Provide a legal mandate to punish companies that fail to adhere to specific levels of quality control.

This is the only workable solution - fortunately it fits right into established regulatory frameworks.

-------------

Controversial opinion:

I do think we need some kind of widely-recognized (i.e. not just in Texas) professional licensing system for SEs/SWEs to enable some kind of accountability for bad software products:

...When a building collapses and kills people, the civil engineer-of-record is accountable or serve as witness. Similarly when avionics software kills passengers (MCAS, etc) there should be a software-engineer-of-record to be held accountable or to serve as witness. Change my opinion.

I know there's a big difference between safety-critical software systems and consumer-hostile inkjet printer cartridges ( https://news.ycombinator.com/item?id=28888214 ) - but more and more jurisdictions (especially outside the US) are going to call-out US and international software and hardware companies on their business-practices which means they'll probably institute something like this inevitably.

I agree with you. It is time. Code runs too much of our world to not have a formalized system of accountability. At least in some domains to start.

One thing though, in the US, and in the case of a building, it would be a Structural Engineer not Civil. And specificity a PE, or Professional Engineer who has a personalized rubber stamp mark registered with the state.

At least that’s what I recall from supporting a CAD department 25 years ago.

The difference is that construction is largely doing the exact same thing that has been refined over thousands of years and we know very well how it goes and have formulas to precalculate everything. So you can have a set of building codes which if you follow, are very likely to produce a perfectly fine building.

While software development is completely making things up as you go because it hasn’t ever been done before. Any kind of government regulation would end up as a box checking exercise that wouldn’t add any more safety and probably introduce problems when products have nonsensical decisions added in to fit with some requirements.

I'll add that we expect software to work on highly heterogeneous systems, too.

If you're working on a bridge, you known exactly the terrain you're required to span. The engineers battle with a lot of integration issues, but at least they know what they're dealing with.

With software development, well, who's to say what integration issues that millions of people might face?

On the other hand our ability to precalculate everything in construction seems to be fairly novel, in the sense that complex geometries are very hard to calculate without computer simulations. And most buildings we build today are nothing like those we built 200 years ago.

The necessity of modelling building behaviour has pushed the field forwards. For software we know that modelling and verification works in principle, but little time is spent on improving the methods because there's no demand

I counter that with that we’ve got methods of developing relyable software and we’ve got examples of success. We’ve got all sorts of different tiers of testing and verification, we’ve got various CI/CD approaches and NASA seems to be landing one rover after another and flying an freaking helicopter on a freaking another planet, autonomously.

We’ve got the tools to explore unknowns.

Now, as to regulation. It could be written in a way that would relieve that “developer-of-record” out of responcibility provided they did their due diligence and, if new unknown happened that wasn’t foreseen the regulations will adapt and change and make a learning out of it, just like it was with building industry and road rules.

> I counter that with that we’ve got methods of developing relyable software

We don't have methods for reliable spelling, however...

My spelling is horrible, especially when I write on the phone, I know, sorry

You're fine :) it's just ironic

> specific levels of quality control.

Good luck defining that though.

The main difference between programming and engineering is unfortunately that no one wants you to build the same thing over and over. So you have no idea if it will work until you build it.

Please don't point me to formal correctness proofs, they just won't work at scale. Hmm, perhaps some bright mind will come with a proof that correctness proofs are too complex to be practical.

> The main difference between programming and engineering is unfortunately that no one wants you to build the same thing over and over. So you have no idea if it will work until you build it.

In between there is the radical idea of writing code carefully, testing, and documenting it before shipping it. All of us as programmers want to do that, but we have all worked under management that insisted on the opposite.

Define that too :) Budget restrictions aside.

For some young things I'm working with, basic debugging techniques seem to be foreign as well...

The CII Best Practices initiative sets a good set of requirements to qualify. Mission-critical software needs to have a good bus factor, keep its deps up to date, have guards in place for the OWASP Top 10 vulns and others (where appropriate), not lean heavily on badness enumeration, etc.

We can set requirements for certain types of software to get certified for a level of reliability, taking inspiration from the CII Best Practices. Two ways to qualify for a certification can include testing and formal verification; I won't elaborate on the latter as per your request.

Good statement coverage from tests is a necessary but absolutely insufficient requirement for tests; they need good branch coverage, and need to pass a good mutation score threshold. Property-based testing makes this a lot easier.

Fuzz-testing is another good follow-up once these get checked off.

Software that passes the above checks and more can qualify for manual review, looking for common vulns and warranted practices.

Much of what I've brainstormed above applies to complex software; simple/small software is much more manageable and probably doesn't need to be held to such standards.

I generally agree with you, but where do you draw the line on what software needs this accountability? Particularly when things change pretty quickly in the field. As an example, 30 years ago, a lot of the internet was not 'important' yet it grew to critical for most of our systems.

In my opinion, your comment and all the comments replying to it (as of writing this comment) are well-considered arguments with valid points.

To summarise:

- we need a licensing system because it promotes accountability and encourages companies to think long-term even when the short-term benefits are tantalising.

- but everything we do in SWE is so new that any licensing system run the risk of (a) being too loose so as to be easily gamed or ignored (think cookie banners a la GDPR), or (b) being too labyrinthian that it kills innovation

Being a product designer, I am directly affected by many of the same issues as engineers. I would be happy to indulge in some level-headed debate. I will be watching this thread so please reply if you have any insight to add! Thank you.

Is the Texas Software PE exam still there? I looked into it years ago out of curiosity, but now I’m seeing that it might not be around any more[0]

> NCEES discontinued the PE Software exam after April 2019.

I think the industry would benefit from an FE style exam at the very least.

[0] https://ncees.org/engineering/pe/software/

"Show me the incentives and I will show you the outcome." ~ Charlie Munger

> if consumers wanted reliable stuff, they'd buy it.

Trouble is, often I can’t when I want to because no one’s making it—that the industry (whatever industry, you find this in many of them) has accepted mediocrity.

For software specifically, my observation is that attempts to retrofit reliability, performance and the likes almost always fail: these are properties that you have to deliberately bake in with from the start, and maintain lest you find them difficult to claw back.

> The idea that developers are somehow empowered to a) not do as they're told by their bosses, and b) should just go off on their own and do whatever the hell they want (eg. making things reliable), when it is not what they have been asked or instructed to do... > > ...well, it's a big ask.

While back my brother's band had a song called, Money Goes to the Man. It captured this issue pretty well.

It seems much easier to find examples of the first two than the last two, really. I've been programming now for 30 years. Here are just ten of the major improvements the industry made to software reliability in that time, on its own, without government intervention of any kind:

1. Unit testing.

2. Garbage collection (no more use-after-free bugs).

3. Stronger type systems.

4. Then stronger type systems with usability close to that of dynamic type systems.

5. Widespread usage of encryption, signing and sandboxing (hacking being a subset of "stuff that makes software unreliable").

6. Exceptions with useful stack traces, that in some cases can be caught allowing the program to proceed. For example, my IDE doesn't totally die if a plugin hits an assertion whilst analyzing code, it just means that plugin doesn't get to contribute to my editor session.

7. Tightly specified memory models like the JMM.

8. Excellent monitoring platforms.

9. State machine replication like Raft, allowing for entire datacenter outages to be made nearly invisible to end users. Result: Google servers are now more reliable than the internet itself.

10. Ultra-stable operating systems like Linux. In 1995 the most popular OS couldn't manage an uptime of more than ~45 days. Today you can hotpatch the kernel without a reboot.

There are loads more like this. Software today is drastically more reliable than it once was. Meanwhile, what has the government done? I'm trying to think of some, but they've all been failures or actually made things worse. In the security realm, we can thank governments for things like FIPS cryptography, which is hardly relevant outside places where it's mandated because it takes so long to approve what are clearly upgrades. Governments can't even get reliable software out of their own contractors - they're in no position to lecture others on how to do it right when they can't even get their own house in order.

But it's not enough to only consider what governments do for reliability. We must also consider what they do against it. There unfortunately the karmic balance is deeply in the red, because governments routinely stockpile exploits then lose control of them, undermine cryptographic standards and so on. They actually like software being unreliable because they see bugs as weapons. A big part of Google's Project Zero is about imposing software reliability against the will of governments.

In some industries where the consequences of failing software are fatal, e.g. medical devices or vehicles, 3. and 4. are in place and ensure that (usually) nothing bad happens.

2. isn't that important if everyone within an industry has to adhere to the same standards.

For example, GDPR levels the playing field for any company that operates in Europe and ISO27001 etc for many industries. But sure, companies will usually do the minimum required effort - and that only if the threat of fines and audits is high enough.