How many programmers operate under that kind of regulatory and operational constraint regime? I think most don’t.

(In interesting ways this is programming’s greatest boon and curse: if we treated it more like building bridges or cars, the world would be a very different place.)

▲

pdhborges 5 hours ago | parent | next [-]

Touch billing, touch medical data, be at a B2B company that needs to catch all the ISOs to have a chance to land bigger contracts. I don't think it's uncommon.

▲

woodruffw 5 hours ago | parent | next [-]

It might be an unpopular option, but I think the regulatory regimes that control medical and financial privacy as they interact with software are significantly lighter touch than e.g. the regimes that control material quality for bridges and tunnels, much less airplanes.

▲

seemaze 3 hours ago | parent | next [-]

Not in tech, so does the authority granting license to proceed do code reviews?

Because when I submit building plans, they are manually reviewed and approved (or denied) by registered architects, engineers, and planners employed by the authority for just this purpose.

	▲	nsagent 2 hours ago \| parent [-]
		Gaming Commissions oversee gambling machines and will audit code to ensure the RNGs are accurate, return to player meets the expected requirements, and so forth. I'm sure other highly regulated industries also have their code audited.

▲

HeyLaughingBoy 4 hours ago | parent | prev [-]

Not really. In those safety-critical areas, the code really is no different. What is significantly different is the surrounding process.

I had to make some software changes to an old medical device this year. The overwhelming majority of the effort was understanding what the customer wanted and giving them feedback into how that would change the existing system and the risks associated. Then, creating a plan to follow the necessary standard (IEC62304) and creating the associated documentation and getting it reviewed and approved.

The actual code that changed was probably only around 100 LOC but the project took several months. Heck, the code was simple enough that an intern could have done it.

	▲	woodruffw 4 hours ago \| parent [-]
		I left out the code on medical devices for a reason! And similarly for avionics software. (The distinction I’m making is between the code that operates the medical device and the code that operates the app I make doctors’ appointments in. The latter is subjected to a different - and lighter - regime than the former.)

▲

cm11 4 hours ago | parent | prev | next [-]

It's questionable though how much the programmer is operating under it. The programmer's work may need to comply, but there are a bunch of things that can reduce how much the programmer themself deals with it.

There are the executives, the lawyers, the product managers, sometimes the designers, who to varying degrees determine this before they land in the requirements the programmer sees. But there are also the libraries and APIs the company pays to handle compliance so that the company and the programmer doesn't. The programmer implements the library (and may not even had a say in or necessarily care which one was chosen).

▲

pdhborges 3 hours ago | parent [-]

Even if you get a crispy set of requirements from all parties you are still responsible for implementing all of then while making sense of the existing system (and from my experience significant issues arise at this stage when the full extent of requirement implications ia better understood). On top of that you might also be responsible for operating the thing, participate in compliance doc writing and do ongoing maintenace.

	▲	cm11 3 hours ago \| parent [-]
		Yes, these things reduce (not necessarily how to zero) how much compliance the programmer is doing. They aren't figuring out how to get a car legally on the road, they're still figuring out how to get a car to do car things. The compliance questions the engineer sees are largely engineering questions. Sometimes hard engineering questions.

▲

4 hours ago | parent | prev [-]

[deleted]

▲

VorpalWay 2 hours ago | parent | prev | next [-]

While there are for sure a lot of programming jobs that don't touch anything "important", like making dime a dozen websites or apps, I think you underestimate the number of things that need some form of higher quality control.

The level of quality needed (or imposed) will vary. It is a wide spectrum from dealing with banking/transactions (money at risk) to brake controllers and auto pilots (human lives at risk). But there is a lot of this, all over the world.

I work somewhere in the middle (rather slow but extremely heavy industrial equipment, where emergency stop is always a safe if costly option). There are domains where emergency stop is not a thing though: some systems on an aircraft in flight, a pacemaker, etc.

My point is though, that there is a ton of code where stakes are higher than "oops, I guess we will fix it next sprint". And while not all of that have regulatory constraints, sometimes a company realises that the financial cost of issues significant enough that it is worth holding themselves to higher standards anyway.

▲

dofm 4 hours ago | parent | prev | next [-]

Any coder with experience or ability imagines a world where software architects are regulated the way real architects are, and acts accordingly.

I mean, this was drilled into me at uni — that software was not likely to escape regulation forever and that you can't know with certainty how all the code you're writing will be used when you're not observing the use.

For example, under what constraint regime should the calculator app bundled with an OS be written? It's just a little bundled toy app. Until someone under pressure uses it to calculate a medicine dose, expecting it to be a calculator like it says.

Perhaps this gives away my age more than anything else.

	▲	asveikau an hour ago \| parent [-]
		> For example, under what constraint regime should the calculator app bundled with an OS be written? It's just a little bundled toy app. Until someone under pressure uses it to calculate a medicine dose, expecting it to be a calculator like it says. This captures a sentiment I have often felt when people don't take bugs seriously. Or don't take it seriously that they introduced regressions. You should feel personal responsibility for your bugs. When your shit doesn't work, and people are trying to use it, you are basically hurting them, personally. But it seems with the increase of AI coding, the industry is going the other direction. Nobody seems to care about bugs introduced by slop coding. Except perhaps the users.

▲

hakunin an hour ago | parent | prev | next [-]

That's why I said "that you can use AND meets regulation". All software on average.

▲

skydhash 5 hours ago | parent | prev [-]

I think most do. You often sees that OSS often provide a disclaimer that they’re not liable for damages. You can’t easily do that when you provide a paid service. B2B often have SLA contracts that usually keeps everyone on their toes and not sling bugs right and left.