The Software Industry Is Still the Problem(queue.acm.org)
queue.acm.org
The Software Industry Is Still the Problem
https://queue.acm.org/detail.cfm?id=3489045
80 comments
It's standard practice in Switzerland to do shoddy construction jobs then declare bankruptcy, buh-bye. Good news is, the parliament is working to outlaw those folks opening new construction firms. There are solutions, but apparently only when the state intervenes...
The construction industry in Quebec has been synonymous with organized crime for many decades. Olympic stadiums falling down. Bridges over freeways collapsing and crushing commuters. Cutting one limb off a rotten tree does not stop the rot if it goes all the way to the roots.
This is also standard for roofing companies in Quebec, I think. They can offer any guarantee they please, since the company won't be around for long enough.
I wonder what the rest of the construction companies think about all these regulations and what was the impact in costs and supply.
Other engineering sectors do have this kind of liability. What do these sectors have as well? Standards. If a house needs to be built, there are _loads_ of safety regulations to follow. Standards to adhere to. Inspections to be had. Only then is someone allowed to move in.
Software? Decisions are often made without either knowledge or a plan. Agile is a thing. Deadlines are shorter than ever. Also: ideally it needs to be for free. Just pick up that package from Github, it should be good enough (maybe it even has Tests, but who cares, really).
The software projects that are heavily regulated? Take forever to plan and complete. Massive budgets. And still usually are not able to manage to be bug free.
Also: software is really, really complex. And: it is easy to attack. Let's be real: other engineering projects are really easy to break as well - some well placed C4 usually does the trick. But it is hard to get C4. Hard to get access. Also, hopefully, there's an ethical barrier to doing it. Software on the other hand? From home. And once there is an angle of attack, it can attack millions of targets at once. And there are no visible victims, at least not right away, so the ethical barrier is lower as well.
Ok I'm rambling. Anyway. This, as is software, is a complex issue. And liability could totally be a thing, but that means an end to ad-financed applications or 2$/user/month services. You get what you pay for (well, sometimes not even then, but you definitely do not get anything for cheap any more). Perfect example: super-cheap IoT devices from China. Well engineered ones doing basically the same thing? 10x, sometimes 100x the price.
Software? Decisions are often made without either knowledge or a plan. Agile is a thing. Deadlines are shorter than ever. Also: ideally it needs to be for free. Just pick up that package from Github, it should be good enough (maybe it even has Tests, but who cares, really).
The software projects that are heavily regulated? Take forever to plan and complete. Massive budgets. And still usually are not able to manage to be bug free.
Also: software is really, really complex. And: it is easy to attack. Let's be real: other engineering projects are really easy to break as well - some well placed C4 usually does the trick. But it is hard to get C4. Hard to get access. Also, hopefully, there's an ethical barrier to doing it. Software on the other hand? From home. And once there is an angle of attack, it can attack millions of targets at once. And there are no visible victims, at least not right away, so the ethical barrier is lower as well.
Ok I'm rambling. Anyway. This, as is software, is a complex issue. And liability could totally be a thing, but that means an end to ad-financed applications or 2$/user/month services. You get what you pay for (well, sometimes not even then, but you definitely do not get anything for cheap any more). Perfect example: super-cheap IoT devices from China. Well engineered ones doing basically the same thing? 10x, sometimes 100x the price.
"Let's be real: other engineering projects are really easy to break as well - some well placed C4 usually does the trick. But it is hard to get C4. Hard to get access"
Who breaks into anything with C4? You can buy a battery powered drill and angle grinder for $300, and break into anything thats not a military bunker. Or you can learn to use lockpicks, and break into most houses for $20.
However, what we have in software, is customer finding out that the door was a mirage and you could wall right through it, or keys being sold on the black market
Who breaks into anything with C4? You can buy a battery powered drill and angle grinder for $300, and break into anything thats not a military bunker. Or you can learn to use lockpicks, and break into most houses for $20.
However, what we have in software, is customer finding out that the door was a mirage and you could wall right through it, or keys being sold on the black market
Yes, and those engineers have their standards because of liability. The article meanders somewhere in the vicinity of that point. I lost track because I was paying too much attention to not stepping on his lawn.
Yes that's kind of what I meant. And we could have those standards for software too (we do, kind of, in the banking and health sector). But with all that which follows those standards - higher cost, lower speed, fewer innovations.
Oh, I so wish us to have standards! There won't be any of them anytime soon, sadly. Even when you have unquestionable benefits going from a dynamic language to a statically strongly typed one (as was shared by a team moving from JS to Rust in the last few weeks here on HN) people still bikeshed and pick apart any word and sentence to hell and back just so their pet idea and favourite language magically happens to be the end-all be-all of programming.
(Let this not be read as if I am a zealot for static strong languages -- when you have to prototype stuff, the dynamic languages are a god send!)
Truth is, a lot of us the software devs are divas -- and I've been guilty of that in the far past as well, and I am very ashamed remembering every minute of it.
But you can't just pass wisdom and tell the younger devs: "STFU and listen to experience and follow established good practices". We all walk our own road to wisdom and sadly that takes a while and in the meantime we can ruin some businesses. :( And/or the job of the next person after us.
(Let this not be read as if I am a zealot for static strong languages -- when you have to prototype stuff, the dynamic languages are a god send!)
Truth is, a lot of us the software devs are divas -- and I've been guilty of that in the far past as well, and I am very ashamed remembering every minute of it.
But you can't just pass wisdom and tell the younger devs: "STFU and listen to experience and follow established good practices". We all walk our own road to wisdom and sadly that takes a while and in the meantime we can ruin some businesses. :( And/or the job of the next person after us.
Software is buggier than buildings because it is built on human made abstractions all the way down. You can reason about a structure if you know where the buck stops (Newtonian physics basically). Computer software isn’t that.
"Software is buggier than buildings because it is built on human made abstractions all the way down."
Software is buggier because: - testing is expensive and takes time so it is a good candidate for cost saving - "atomic requirements" - there is no such thing. As long as your function is part of a program you cannot consider it separately. - "if it compiles ship it" - "let's turn on -Werror and ship it". Let the user fix the bugs. - "All the world is a VAX". ... and other such great ideas which have nothing to do with engineering. If builders build buildings the way programmers build SW: every year the building code will change and you will not be able to connect old buildings to utilities ( or they will be disconnected), nobody will agree on a mean of transportation of building materials and after you build it someone will steal all your belongings because the windows will have no locks.
Software is buggier because: - testing is expensive and takes time so it is a good candidate for cost saving - "atomic requirements" - there is no such thing. As long as your function is part of a program you cannot consider it separately. - "if it compiles ship it" - "let's turn on -Werror and ship it". Let the user fix the bugs. - "All the world is a VAX". ... and other such great ideas which have nothing to do with engineering. If builders build buildings the way programmers build SW: every year the building code will change and you will not be able to connect old buildings to utilities ( or they will be disconnected), nobody will agree on a mean of transportation of building materials and after you build it someone will steal all your belongings because the windows will have no locks.
How about, "if material science advanced as fast as computers, there would be 30% better insulation and 30% cheaper way to build 30% more efficient buildings every year". Software is not build on as stable of a basis because hardware changes and more is possible. E.g.: with on-device ML possibilities you can now do way more things, but now we also need to figure out how to best do them. The fact that we have more cores mean that we can serve more clients by a single machine, in-theory, but we also need to rewrite everything in parallel.
When was the last time it was "worth it" to tear down a 10 year old building because rebuilding one would save enormous amount of money in a couple of years?
I think there is a balance to find in both, I'm not saying we should rush into everything, but expecting that everything is always super stable, would absolutely end up in the nice features being available later than technically possible.
When was the last time it was "worth it" to tear down a 10 year old building because rebuilding one would save enormous amount of money in a couple of years?
I think there is a balance to find in both, I'm not saying we should rush into everything, but expecting that everything is always super stable, would absolutely end up in the nice features being available later than technically possible.
> As I write this on an early July morning, 200-plus corporations, including many retail chains, have inoperative IT because extortionists found a hole in some niche, third-party software product most of us have never heard of.
As I write this, millions of cars have gotten stolen due to vulnerable lock mechanism. A thief can with simple toools just open the door, start the car and drive away. Do we sue the engineer designing the lock for billions in damages? No. It isn't reasonable to blame engineers for everything.
As I write this, millions of cars have gotten stolen due to vulnerable lock mechanism. A thief can with simple toools just open the door, start the car and drive away. Do we sue the engineer designing the lock for billions in damages? No. It isn't reasonable to blame engineers for everything.
You having your car stolen, and software used across a company having a vulnerability are different in terms of scale though. If a whole shipment of cars was stolen due to a lock flaw (which is admittedly contrived), then I'd imagine whoever owned the cars would have a problem with the maker of the cars.
But almost a million cars gets stolen a year in US, totalling billions of value. How is that not the same scale?
Because it's distributed and the larger the spread, the smaller the obvious scale.
For example, let's say I'm a murderer and kill ever resident of a single street, one household a day. That's way too much of a coincidence to ignore. But if I did the same number across a larger area, maybe you get different police forces that haven't thought to talk to each other and no one spots the connection until much later.
The same applies here. If you personally have faulty software, it's not great, but you probably move on. If your employer buys the same software for all of its employees, then the scale of the problem is much more obvious and the actual cost of the problem is a lot larger to a single entity.
For example, let's say I'm a murderer and kill ever resident of a single street, one household a day. That's way too much of a coincidence to ignore. But if I did the same number across a larger area, maybe you get different police forces that haven't thought to talk to each other and no one spots the connection until much later.
The same applies here. If you personally have faulty software, it's not great, but you probably move on. If your employer buys the same software for all of its employees, then the scale of the problem is much more obvious and the actual cost of the problem is a lot larger to a single entity.
Sorry, this analogy does not hold up.
First of all, you're comparing unintended software vulnerabilities to physical locks; being able to open a lock with a lockpick is an element of the design! Everyone knows this going in!
That aside, ask yourself what car manufacturers have to do to prove the safety/security of everything in their supply chain down to nuts and bolts, and what the consequences are when they make a mistake.
Now compare that to how modern consumer software projects do dependency management and verification, and what happens when they have a whoopsie because some open source library they pulled from GitHub with a "no warranty" license exposed them to a critical data breach. In my experience they throw their hands up and say "meh sorry, software is hard."
First of all, you're comparing unintended software vulnerabilities to physical locks; being able to open a lock with a lockpick is an element of the design! Everyone knows this going in!
That aside, ask yourself what car manufacturers have to do to prove the safety/security of everything in their supply chain down to nuts and bolts, and what the consequences are when they make a mistake.
Now compare that to how modern consumer software projects do dependency management and verification, and what happens when they have a whoopsie because some open source library they pulled from GitHub with a "no warranty" license exposed them to a critical data breach. In my experience they throw their hands up and say "meh sorry, software is hard."
It's not exactly the same though. Stolen cars does not have the potential to affect your daily day life as broken software can.
I agree that the blame does not lie on the engineers that created the cars or software though. In the end it's a problem of cost, you could write better software, but it would cost you time, money and shifted focus in the education of software developers and so on. Users are not willing to pay for that cost, they are very upset when reality bites them in the rear though...
I agree that the blame does not lie on the engineers that created the cars or software though. In the end it's a problem of cost, you could write better software, but it would cost you time, money and shifted focus in the education of software developers and so on. Users are not willing to pay for that cost, they are very upset when reality bites them in the rear though...
You can't really steal a modern car, at least with simple tools. Everything is now digitally interlocked by a password contained within the key and keyfob itself.
> It may be less obvious why the state cares who runs pet shops, inseminates cattle, or performs zoological taxidermy, but if you read the applicable laws, you'll learn that animal welfare and protection of endangered species have many and obscure corner cases.
But how did many those laws come to be?
Is it because the state cares about these professions a-priori, or because established players in those industries lobbied to restrict who can enter the profession in order to protect their market position and comparative advantage?
And yes, the latter can be true while also it leading to an outcome that produces higher quality than if thise laws were not there - but quality may not have been the reason the laws were proposed in the firt place.
But how did many those laws come to be?
Is it because the state cares about these professions a-priori, or because established players in those industries lobbied to restrict who can enter the profession in order to protect their market position and comparative advantage?
And yes, the latter can be true while also it leading to an outcome that produces higher quality than if thise laws were not there - but quality may not have been the reason the laws were proposed in the firt place.
Are you saying we're safe from exploding toilets because of regulatory capture by a few corrupt individuals? Bring on the corruption!
Im not trying to establish a categorical imperative that applies to everything, such as toilets, but may make sense in certain industries (maybe zoological taxidermy)?
The larger point is why the software industry has avoided regulatory capture or eschews certification in contrast to other markets.
In other words, more boadly, is it the government that pushes for these laws, or the market that demands/asks for them?
(Also, it might helpful to differentiate B2B vs B2C here).
The larger point is why the software industry has avoided regulatory capture or eschews certification in contrast to other markets.
In other words, more boadly, is it the government that pushes for these laws, or the market that demands/asks for them?
(Also, it might helpful to differentiate B2B vs B2C here).
> The larger point is why rhe software industry has avoided regulatory capture
I would argue that the software industry is not run by software developers but by the cowboys in suits at the Excel and Powerpoint rodeo in the boardroom. It's rife with regulatory capture, but software developers in that environment are considered a liability to be minimized. Tweaking that expense line in your presentation to the shareholders means hiring the cheapest labour possible and spending as little as possible on their development, training, and certification. Your investment in lobbying authorities to keep regulation at bay has an enticing rate of return.
I would argue that the software industry is not run by software developers but by the cowboys in suits at the Excel and Powerpoint rodeo in the boardroom. It's rife with regulatory capture, but software developers in that environment are considered a liability to be minimized. Tweaking that expense line in your presentation to the shareholders means hiring the cheapest labour possible and spending as little as possible on their development, training, and certification. Your investment in lobbying authorities to keep regulation at bay has an enticing rate of return.
I'm tring to highlight and draw comparisons _between_ industries in order to discover what is _different_ between them.
I don't think the claim that software devs are oppressed by management (as if other industries do not have management) and would run things better themselves (they wouldn't) sheds any light on discovering those differences.
I don't think the claim that software devs are oppressed by management (as if other industries do not have management) and would run things better themselves (they wouldn't) sheds any light on discovering those differences.
On what basis should a developer be held liable for damage caused by software? Certainly a group of 'experts' could identify outright negligence.
But in engineering professions, the standards are well understood, and measurable. Software is not the same at all.
The whole argument appears spurious, and the arguer, sanctimonious.
But in engineering professions, the standards are well understood, and measurable. Software is not the same at all.
The whole argument appears spurious, and the arguer, sanctimonious.
Yeah - and why the developer, exactly?
Not liable:
- The CEO that set infeasible targets and pocketed a big bonus for meeting shareholder expectations.
- The sales person that sold the project for too little money and pocketed a big bonus for bringing it in.
- The manager who allocated too few hours and got a raise for finishing the project in time.
- The designer who drew all the cute boxes on the powerpoint presentation to show how it was going to work.
- The testers who failed to find whatever the problem was.
Liable:
- The poor chap who wrote the code, worked extra unpaid hours to get it done at all within the timescale imposed, didn't have a say in how it was going to be implemented, and didn't even get so much as a thank you.
Not liable:
- The CEO that set infeasible targets and pocketed a big bonus for meeting shareholder expectations.
- The sales person that sold the project for too little money and pocketed a big bonus for bringing it in.
- The manager who allocated too few hours and got a raise for finishing the project in time.
- The designer who drew all the cute boxes on the powerpoint presentation to show how it was going to work.
- The testers who failed to find whatever the problem was.
Liable:
- The poor chap who wrote the code, worked extra unpaid hours to get it done at all within the timescale imposed, didn't have a say in how it was going to be implemented, and didn't even get so much as a thank you.
When it comes down to it, most software bugs don't matter. Reimburse the customer, wait a few days for a dev to fix something, whatever, it'll get resolved and everyone will be whole again. Contrast this with construction, if there's a "bug" in the building, people can die, or lose housing, or companies can lose large amounts of money. Bug in a billing system? Just try and pay again next week.
In industries where software bugs do have large consequences, well they tend to be heavily regulated industries already: finance, aerospace, government systems, automated cars, elevators, medical devices.
In industries where software bugs do have large consequences, well they tend to be heavily regulated industries already: finance, aerospace, government systems, automated cars, elevators, medical devices.
Not to mention that buildings are equally full of all kinds “bugs” that are more toward the annoying end of the spectrum. You learn to live with them or fix them.
Realistically, I’m not sure I’ve ever seen something created by humans that was entirely bug-free.
Realistically, I’m not sure I’ve ever seen something created by humans that was entirely bug-free.
Yes, it's not an industry problem, it's just that most software isn't critical. When software is critical, it's also handled differently. I worked on critical car software, where a bug is expected to cause a safety hazard, and can lead to a car crash. The development process is completely different from some non-critical web service. FMEA analysis, breaking down the software into ASIL levels per component so some components get the very thorough ISO 26262 procedures, every code change has to be traced to a requirement and reviewed by two people. Tooling requires 100% branch coverage in tests, anything that's manually excluded from tests has to have a written justification and manual analysis. Code to be written strictly in MISRA C, any non-compliance detected by static analysis blocks the merge until resolved or manually verified and documented.
Developing that kind of software is so different from most non-critical software that it might as well be different industries altogether.
Developing that kind of software is so different from most non-critical software that it might as well be different industries altogether.
The article claims is that stability on a national level involves a large number of these non-critical systems all working correctly on a systemic level.
well that's true not just for software. For society has a whole to work, you need a bunch of non-critical system to work well together. It doesn't mean you are required to have a license to be alive (However, that would make a great plot for a Black Mirror episode I guess)
The other types of engineering the author refers to that are subject to certification involve the physical safety of other people.
But still, plenty of software development roles are subject to professional liability, particularly where the work is linked to people’s physical safety. As a contractor or director of a company providing software services, I’ve been required to have professional indemnity and public liability insurance, and part of that involves verification that I’m sufficiently educated and experienced to be competent enough to mitigate the risk.
It doesn’t make sense for there to be industry-wide liability standards, as roles and risks vary so much, and certification comes at a huge cost. It’s absurd that the same standards of liability would apply to an aviation software job vs the part time IT guy at said sub-20-person office whose responsibilities are limited to setting up MS ActiveDirectory and keeping the printers running.
This is a rant about a non-problem.
But still, plenty of software development roles are subject to professional liability, particularly where the work is linked to people’s physical safety. As a contractor or director of a company providing software services, I’ve been required to have professional indemnity and public liability insurance, and part of that involves verification that I’m sufficiently educated and experienced to be competent enough to mitigate the risk.
It doesn’t make sense for there to be industry-wide liability standards, as roles and risks vary so much, and certification comes at a huge cost. It’s absurd that the same standards of liability would apply to an aviation software job vs the part time IT guy at said sub-20-person office whose responsibilities are limited to setting up MS ActiveDirectory and keeping the printers running.
This is a rant about a non-problem.
> It’s absurd that the same standards of liability would apply to an aviation software job vs the part time IT guy
While I agree, the reality is that the part time IT guy is generally far more certified than the high paid software developer, which I find far more absurd.
While I agree, the reality is that the part time IT guy is generally far more certified than the high paid software developer, which I find far more absurd.
> generally far more certified
Hardly. Any software developer working on systems that risk people’s safety - eg avionics, automotive systems, medical devices, traffic control systems - would be required to have advanced university qualifications. Google at least used to require all its software engineers to have masters degrees. Do they still? People I’ve know to work in software dev jobs at Microsoft and even mid-level companies like TripAdvisor and SurveyMonkey have PhDs. Other tech companies like IBM and Accenture sure would require at least bachelor degrees.
But sure, plenty of software developers have no formal qualifications or liability. And they’re not working on stuff that directly risks people’s physical safety.
Hardly. Any software developer working on systems that risk people’s safety - eg avionics, automotive systems, medical devices, traffic control systems - would be required to have advanced university qualifications. Google at least used to require all its software engineers to have masters degrees. Do they still? People I’ve know to work in software dev jobs at Microsoft and even mid-level companies like TripAdvisor and SurveyMonkey have PhDs. Other tech companies like IBM and Accenture sure would require at least bachelor degrees.
But sure, plenty of software developers have no formal qualifications or liability. And they’re not working on stuff that directly risks people’s physical safety.
That completely misses the point.
Some developers have some certifications to cover employer liability. You cannot be a software developer for the US federal government without at least a Security+ certification, but this is rare among developers. In most of my giant corporate employers you didn’t need even a bachelors degree.
Regardless of industry or employer you cannot get hired as a help desk IT guy without a laundry list of certifications. It is a night and day difference.
Some developers have some certifications to cover employer liability. You cannot be a software developer for the US federal government without at least a Security+ certification, but this is rare among developers. In most of my giant corporate employers you didn’t need even a bachelors degree.
Regardless of industry or employer you cannot get hired as a help desk IT guy without a laundry list of certifications. It is a night and day difference.
You said you agreed with my main point so I probably should have left it at that, but for the record:
The OP says: Most organizations seem to hire their first part-time IT person before they reach 20 employees. When that first IT person is replaced, the new IT person bores everybody with complaints about how "totally incompetent" the first person must have been, and, usually, is correct. When you hire somebody's teenage kid, you almost invariably get the competence you pay for.
By "somebody's teenage kid" I gather we're meant to assume this character is not qualified or certified; that's the very point of the article. I've certainly known of such people, and have even been that person. Indeed the first five years of my career were in helpdesk and network design roles, and I had no certifications.
Sure, I know what you mean, that to be serious support professional for products from vendors like Microsoft, Cisco, Oracle, etc, you need certifications. But plenty of small-business networks are set up by young, inexperienced, uncertified people such as family members and friends, and if the business stays small it's often fine.
But sure, among software developers, plenty of highly paid ones don't have qualifications/certifications, where it's not deemed necessary by employers/clients. And plenty do, where it is deemed necessary or legally required.
I guess the real point is that people are paid more for their impact and the uniqueness of their abilities, not their certifications, and it's more common to be high-impact and unique as a developer than as a helpdesk tech.
The OP says: Most organizations seem to hire their first part-time IT person before they reach 20 employees. When that first IT person is replaced, the new IT person bores everybody with complaints about how "totally incompetent" the first person must have been, and, usually, is correct. When you hire somebody's teenage kid, you almost invariably get the competence you pay for.
By "somebody's teenage kid" I gather we're meant to assume this character is not qualified or certified; that's the very point of the article. I've certainly known of such people, and have even been that person. Indeed the first five years of my career were in helpdesk and network design roles, and I had no certifications.
Sure, I know what you mean, that to be serious support professional for products from vendors like Microsoft, Cisco, Oracle, etc, you need certifications. But plenty of small-business networks are set up by young, inexperienced, uncertified people such as family members and friends, and if the business stays small it's often fine.
But sure, among software developers, plenty of highly paid ones don't have qualifications/certifications, where it's not deemed necessary by employers/clients. And plenty do, where it is deemed necessary or legally required.
I guess the real point is that people are paid more for their impact and the uniqueness of their abilities, not their certifications, and it's more common to be high-impact and unique as a developer than as a helpdesk tech.
But a dev is often part of a pipeline that includes e.g. dedicated QAs. I'd also argue that common hardware is a lot less varied that common software architectures.
"This is a rant about a non-problem."
Every time I buy a 'smart' version of a product, whether its a light or coffee machine, it becomes 10x less reliable.
When your coffee machine is mining bitcoins because it's software is written in javascript and someone paid the author of left pad, that funny. When half the city comes to a hault becauae the same thing happened to traffic lights..
Every time I buy a 'smart' version of a product, whether its a light or coffee machine, it becomes 10x less reliable.
When your coffee machine is mining bitcoins because it's software is written in javascript and someone paid the author of left pad, that funny. When half the city comes to a hault becauae the same thing happened to traffic lights..
For consumer products like coffee machines and light bulbs there are consumer protection laws, electronic device safety certifications, product review sites, brand reputation and word of mouth recommendations. It’s hard to imagine what kind of regulations would further improve things. (Consider also that many of these products are designed and produced in other countries, so we need to figure out how to force all those other countries to enforce the certifications that we demand).
I’ve not heard of a traffic light failure due to the control system mining Bitcoin, and any software engineer who did that or allowed it to happen would find their career over pretty quickly.
I’ve not heard of a traffic light failure due to the control system mining Bitcoin, and any software engineer who did that or allowed it to happen would find their career over pretty quickly.
I am sorry but the arguments about brand betray terrible naivity, hundreds on innocent people have gone to jail because of software failure that was kept secret.
https://www.computerweekly.com/news/252496560/Fujitsu-bosses...
"It’s hard to imagine what kind of regulations would further improve things"
1 simple law: for every product, place all firmware source-code in escrow, inspectable by police, MI6 and Courts in case of major hacks, breakdowns, and lawsuits.
https://www.computerweekly.com/news/252496560/Fujitsu-bosses...
"It’s hard to imagine what kind of regulations would further improve things"
1 simple law: for every product, place all firmware source-code in escrow, inspectable by police, MI6 and Courts in case of major hacks, breakdowns, and lawsuits.
> I am sorry but the arguments about brand betray terrible naivity
You were complaining about coffee machines and lights. Not vast custom-built corporate/government IT platforms. Completely different products and a completely different discussion. And besides, the staff at Fujitsu working on such a system would likely be university qualified and certainly subject to liability insurance and contractual requirements specified by the client – which is exactly what the original article is calling for.
> 1 simple law
It's not simple at all, to completely rewrite every IP law and technology business convention in every country in the world :) And that's not what the article is calling for. It's just saying software developers should be qualified and insured.
You were complaining about coffee machines and lights. Not vast custom-built corporate/government IT platforms. Completely different products and a completely different discussion. And besides, the staff at Fujitsu working on such a system would likely be university qualified and certainly subject to liability insurance and contractual requirements specified by the client – which is exactly what the original article is calling for.
> 1 simple law
It's not simple at all, to completely rewrite every IP law and technology business convention in every country in the world :) And that's not what the article is calling for. It's just saying software developers should be qualified and insured.
"You were complaining about coffee machines and lights. "
'vast custom-built corporate/government IT platforms' are actually worse than most consumer products I had to deal with. The entire industry being infantile and irresponsible in every area it touches, from coffee machines to ATMs running windows XP and vulnerable oil pipelines.
"staff at Fujitsu working on such a system would likely be university qualified"
Traders were qualified in 2008, the crash still happened. You are missing the point.
The system encourages risk and staggering incompetence from leadership, untill the firms are held accountable and subject to real scrutiny, nothing will change. I know, first hand, a payment company which decided to switch from Perl to JS, and fired all Perl developers. Then they realised it's broken and they have no-one to fix it before JS system is ready.
"It's not simple at all, to completely rewrite every IP law"
You don't need to change IP law or anything else, you just need to equip justice system to inspect software and hold irresponsible gamblers accountable. If a Car company is accused of gross negligence, you can take a car apart and check what's going on, this is accomplishing the same for software, and to make sure it's not suddenly lost, deleted, etc. What is the "technology business convention" that we have to change? We already use version control.
We do the same for plans of buildings and aircraft, they don't suddenly belong to the government.
'vast custom-built corporate/government IT platforms' are actually worse than most consumer products I had to deal with. The entire industry being infantile and irresponsible in every area it touches, from coffee machines to ATMs running windows XP and vulnerable oil pipelines.
"staff at Fujitsu working on such a system would likely be university qualified"
Traders were qualified in 2008, the crash still happened. You are missing the point.
The system encourages risk and staggering incompetence from leadership, untill the firms are held accountable and subject to real scrutiny, nothing will change. I know, first hand, a payment company which decided to switch from Perl to JS, and fired all Perl developers. Then they realised it's broken and they have no-one to fix it before JS system is ready.
"It's not simple at all, to completely rewrite every IP law"
You don't need to change IP law or anything else, you just need to equip justice system to inspect software and hold irresponsible gamblers accountable. If a Car company is accused of gross negligence, you can take a car apart and check what's going on, this is accomplishing the same for software, and to make sure it's not suddenly lost, deleted, etc. What is the "technology business convention" that we have to change? We already use version control.
We do the same for plans of buildings and aircraft, they don't suddenly belong to the government.
The assertion in the article is that everyone selling software products and services should be qualified and insured.
You seem to be arguing for things much more far-reaching than that, which you’re welcome to do, but I’m here to discuss the contents of the article, thanks.
You seem to be arguing for things much more far-reaching than that, which you’re welcome to do, but I’m here to discuss the contents of the article, thanks.
I think you might be missing the forest for the trees a bit. Many industries have a very wide range of certifications and there's no reason IT couldn't be the same. For example, think doctors: some are certified for surgery, some are certified to give physiotherapy, some are certified to refer you to other doctors etc. I don't think cost is a reasonable argument either — you wouldn't want a plumber with no knowledge of their profession just because they're cheaper. There's (usually) no life-threatening danger involved, but you can end up with very large expenses if something goes wrong.
There’s more diversity in roles and risks in IT than there is in medicine. But even still there are still jobs related to health that don’t require qualifications and certification - e.g. massage and fitness training.
Plumbing certainly involves physical safety and health; poor plumbing work can damage the building leading to collapse, or cause a fire/explosion, water contamination or electrical faults leading to injuries or fatalities.
Plumbing certainly involves physical safety and health; poor plumbing work can damage the building leading to collapse, or cause a fire/explosion, water contamination or electrical faults leading to injuries or fatalities.
That's okay, no one will be able to afford software any more afterwards.
I suppose the likes of MS could get away with selling a bug free operating system for only 100k/seat. All the other cheap apps with less than millions of customers will simply vanish.
I suppose the likes of MS could get away with selling a bug free operating system for only 100k/seat. All the other cheap apps with less than millions of customers will simply vanish.
Banks and financial entities are the ones that have the hardest government regulations, including how they write software. Regulating software engineers would just make the rest of the industry look more like those, I wouldn't call that an improvement. The problem is that we currently don't know how to properly regulate software engineering to get good results. Regulations doesn't even seem to protect against vulnerabilities, so why even bother until we understand better how to regulate it?
Oh look. An institution who’d be the first to sell certifications wants to make certifications mandatory. Nah, thanks. At least I’m Software one can still innovate without having to cut through miles of red tape.
You're also free to build your own furniture even though there are regulations on structures. A structure is both life-threatening when it fails and will almost inevitably end up in the hands of someone who wasn't the original builder at some point in its life.
I should always be free to write software to run my model trains, or even somoene else's model trains however I choose. Making the same argument for real trains (which already have lots of regulation) is much harder.
That said, if licensing did happen, there would definitely need to be tiers. Building software in-house is different than one being sold (saas or on-premise). Regulated industries would each end up with their own licenses, probably.
That said, I go back and forth on this. Something as bureaucratic as licensing doesn't seem like a great solution, but the industry is definitely lacking something. I'm not quite sure what that something is exactly. Maybe we need a split between engineering and labor, similar to construction. Liscenced engineers design and inspect the bridge, unlicensed labor builds it. Similarly, I can usually build small structures without a license, small non-life-critical projects wouldn't need liscenced engineers either.
I should always be free to write software to run my model trains, or even somoene else's model trains however I choose. Making the same argument for real trains (which already have lots of regulation) is much harder.
That said, if licensing did happen, there would definitely need to be tiers. Building software in-house is different than one being sold (saas or on-premise). Regulated industries would each end up with their own licenses, probably.
That said, I go back and forth on this. Something as bureaucratic as licensing doesn't seem like a great solution, but the industry is definitely lacking something. I'm not quite sure what that something is exactly. Maybe we need a split between engineering and labor, similar to construction. Liscenced engineers design and inspect the bridge, unlicensed labor builds it. Similarly, I can usually build small structures without a license, small non-life-critical projects wouldn't need liscenced engineers either.
The customer is paying for it either way. Do you want liability insurance on your critical software project? Sure! But it'll just balloon the already ridiculous costs and a fraction of that money will maybe be spent on educating the engineers and ensuring the system is secure.
On an individual level, expect to see this: "Our records indicate that you have previously committed (a minor, unrelated change) to a software repository that was later exploited, unfortunately we are not able to offer you a position at this time (due to insurance reasons)"
On an individual level, expect to see this: "Our records indicate that you have previously committed (a minor, unrelated change) to a software repository that was later exploited, unfortunately we are not able to offer you a position at this time (due to insurance reasons)"
I think rather than broadly comparing software engineering to other engineering professions in general, it would be more apt to compare it to plumbing specifically. Building bridges, planning houses and roads, etc often comes with strings attached because lives are at stake. Focusing on this distinction and then dismissing the argument as it's not applicable to software short of a few specific areas is easy, but missing the forest for the trees. Plumbing is a better comparison. Most of the time, there's no life-threatening danger involved (although there are exceptions). In general though, failures are simply both very unpleasant and get expensive fast. If you need to replace an old tap you may be able to do get it done on the cheap or even do it yourself, but if you want to run water for a whole building, you will most certainly want someone who comes with certifications, liability insurance, etc. In the long run, as a society we would benefit greatly from introducing varying kinds and levels of certification in the software industry, and for similar reasons. Like plumbing, there's no problem if you do smaller things around your own house. But if you want to build software that sits at the heart of say nationally important systems you should be tested before you're let at the wheel.
So that would mean I could f.e. Sue Microsoft if they push an update that breaks my whole network?
... I like this idea
... I like this idea
Say hello to no updates ever.
Then again, the bad publicity.
It is a great idea, but this is not going to work. The difference between construction and software engineering is the number of active users. If damage is made and people sue, your liability is limited by 1-10000 building occupants and visitors. No insurance company will take the risk of paying to 1M-1B active users of software.
And of course there is also a problem of implementation. Even with deadline in 10 years industry will not be able to certify majority of the engineers or develop an engineering process where licensed engineer in USA or EU can take responsibility for the code written by 10 engineers from another country with different standards (they can even be licensed, but those licenses won’t be recognized abroad).
And of course there is also a problem of implementation. Even with deadline in 10 years industry will not be able to certify majority of the engineers or develop an engineering process where licensed engineer in USA or EU can take responsibility for the code written by 10 engineers from another country with different standards (they can even be licensed, but those licenses won’t be recognized abroad).
> "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization."
Except that isn’t what software engineers largely do, we aren’t building the nth copy of the same building with a slightly different skin. Those kind of largely canned projects are straightforward and mostly offshored to low cost countries.
The other type of project is complex and unpredictable because no one knows the full scope of the project, the specifications and interactions. Most of the complexity and time in software engineering is getting that sorted, not the coding. Not to say coding something complex and non-trivial is easy, but the main challenges aren’t the code IMHO
Except that isn’t what software engineers largely do, we aren’t building the nth copy of the same building with a slightly different skin. Those kind of largely canned projects are straightforward and mostly offshored to low cost countries.
The other type of project is complex and unpredictable because no one knows the full scope of the project, the specifications and interactions. Most of the complexity and time in software engineering is getting that sorted, not the coding. Not to say coding something complex and non-trivial is easy, but the main challenges aren’t the code IMHO
Every building is unique construction project regardless of how much you can save on using existing blueprints or readymade components. You need to consider soils, unevenness of surface, connection to communications and roads etc etc.
Construction projects are indeed the same as software projects, when you consider the planning and execution. Even in that some discoveries may happen at the last stages, adjustments have to be made, blueprints have to be changed.
The main challenge of building a building that does not collapse isn't how to swing a hammer.
> Except that isn’t what software engineers largely do, we aren’t building the nth copy of the same building with a slightly different skin.
That’s exactly what most developers do.
There is far greater variation in boring bridges spanning small streams than most web applications and yet after more than 20 years we still can’t figure it out without some giant framework to do most of it for us.
That’s exactly what most developers do.
There is far greater variation in boring bridges spanning small streams than most web applications and yet after more than 20 years we still can’t figure it out without some giant framework to do most of it for us.
Cost of replicating software is near zero, if you want the same thing as the next guy you can have it right now, no schedule risk.
Except that isn’t what they want, they want the same “except for this, and with this extra, and change that…”. And we are back at the discover the spec stage again
Except that isn’t what they want, they want the same “except for this, and with this extra, and change that…”. And we are back at the discover the spec stage again
You are overstating requirements gathering and then somehow confusing that for building anything technical. This only exemplifies the incompetence.
Bridge building is only more predictable because it’s more expensive. The same planning problems are still there but are worked out well in advance by people who aren’t so easily confused.
Bridge building is only more predictable because it’s more expensive. The same planning problems are still there but are worked out well in advance by people who aren’t so easily confused.
We know mate, you are preaching to the quer. His point is you cannot exactly replicate a bridge either even if you've got an identical one 300 meters away - the river twists and turns, soil conditions differ, foundations may be different, etc.
You never get to 'copy-paste' anything more conplicated than a shed ir a single-story house
You never get to 'copy-paste' anything more conplicated than a shed ir a single-story house
Liability implies lawyers.
Contracts also imply lawyers.
What if we put the liability requirements into the contract, and see how it goes?
Might we discover that legal language is just another programming language as fraught with peril as the software?
Don't take my word for it: make that legalese happen.
Contracts also imply lawyers.
What if we put the liability requirements into the contract, and see how it goes?
Might we discover that legal language is just another programming language as fraught with peril as the software?
Don't take my word for it: make that legalese happen.
A small internal software group like mine would almost certainly be a casualty of any real increase in software liability.
On the other hand, the inevitable slowing of technology change and consolidation of libraries, languages, and frameworks would be kinda nice. Hard won, deep knowledge of technology that is 20 years old would be worthwhile. And I could finally stop yelling at JavaScript frameworks to get off my lawn.
On the other hand, the inevitable slowing of technology change and consolidation of libraries, languages, and frameworks would be kinda nice. Hard won, deep knowledge of technology that is 20 years old would be worthwhile. And I could finally stop yelling at JavaScript frameworks to get off my lawn.
I view software as a form of literacy as opposed to engineering. Silicon chips - that's engineering. Codifying the process used by a large corporation to tell all its other systems a new joiner has arrived called "bob smith". That's writing something that other humans can read and can be executed by these engineered robots we have.
While my heart is socialist, my head is market-driven. And I think a market solution is the best option here.
But markets only work with informed buyers.
If my literacy idea is right - then no-one can judge software without being software literate (and having access to the source.) Just imagine a world where people had to buy the best books - but that the literacy rate was under 1%. We would have podcasts on that great book, the CEO would sign off on a purchase after and .... - books would be like software is here. Success based on marketing and yes minimising liability (no one ever got fired for buying microsoft). Linux would be samizisat!
I vastly admire Poul's incredible contributions to FOSS - but software liability is best fixed in contracts (where it usually is).
Edit: The only sane way (#) to build liable software is with some form of proof-based modelling - and this is even after decades of research horribly limited and does not reach into areas we wrote or use most software.
I am afraid software is just an extension of the human technology of speech and writing. It is a way to express ourselves in symbolic form outside our brains. It is probably the second most important development in human history - and we need to adapt all of society to be able to harness its benefits without too much harm. The crap IT surrounding us now is the pollution of the first coal driven factories. We will get better - our problem is to do it faster.
On a different note, most software (hence most bad software) is written in house - so the software that makes a bank a bank or a construction company construct, that is mostly already covered by liability. Your bank sends the wrong amount to the wrong bank account? That's been a liability since before the USA was a thing, and so the onus is on the bank to ensure it writes the software correctly. The fact that this is insanely hard implies to me that we need not just "better training for software developers", but "redesign our entire organisations" and probably our whole societies (let's start here: most things written down are done so openly - published or emailed or sent around. Most software code is closed and "proprietary". Change that first)
(#) I can imagine many companies taking on software liability without caring about the risks - but they don't sound like the people I want building airplanes, power stations etc etc.
While my heart is socialist, my head is market-driven. And I think a market solution is the best option here.
But markets only work with informed buyers.
If my literacy idea is right - then no-one can judge software without being software literate (and having access to the source.) Just imagine a world where people had to buy the best books - but that the literacy rate was under 1%. We would have podcasts on that great book, the CEO would sign off on a purchase after and .... - books would be like software is here. Success based on marketing and yes minimising liability (no one ever got fired for buying microsoft). Linux would be samizisat!
I vastly admire Poul's incredible contributions to FOSS - but software liability is best fixed in contracts (where it usually is).
Edit: The only sane way (#) to build liable software is with some form of proof-based modelling - and this is even after decades of research horribly limited and does not reach into areas we wrote or use most software.
I am afraid software is just an extension of the human technology of speech and writing. It is a way to express ourselves in symbolic form outside our brains. It is probably the second most important development in human history - and we need to adapt all of society to be able to harness its benefits without too much harm. The crap IT surrounding us now is the pollution of the first coal driven factories. We will get better - our problem is to do it faster.
On a different note, most software (hence most bad software) is written in house - so the software that makes a bank a bank or a construction company construct, that is mostly already covered by liability. Your bank sends the wrong amount to the wrong bank account? That's been a liability since before the USA was a thing, and so the onus is on the bank to ensure it writes the software correctly. The fact that this is insanely hard implies to me that we need not just "better training for software developers", but "redesign our entire organisations" and probably our whole societies (let's start here: most things written down are done so openly - published or emailed or sent around. Most software code is closed and "proprietary". Change that first)
(#) I can imagine many companies taking on software liability without caring about the risks - but they don't sound like the people I want building airplanes, power stations etc etc.
A developer is more of a writer crafting abstract concepts into flow. Build a house is physical an unrelated
I'd say software is more like math literacy (as opposed to numeracy) which is also fairly poor in many countries.
Keep in mind books/writing have been around for a long time, and language (which writing is arguably a written form of) has been around even longer and vital to both everyday life, and the human psyche.
It's going to be hard to compete there. I'd say simpler things might be achieved first: e.g. use of word-processors and spreadsheets.
Keep in mind books/writing have been around for a long time, and language (which writing is arguably a written form of) has been around even longer and vital to both everyday life, and the human psyche.
It's going to be hard to compete there. I'd say simpler things might be achieved first: e.g. use of word-processors and spreadsheets.
What is the equivalent of open source software in the physical engineering world that this author respects so much? How is it regulated?
If there isn’t such an example, then perhaps software is a category of its own and thus its problems can’t be solved by legacy regulatory tooling.
If there isn’t such an example, then perhaps software is a category of its own and thus its problems can’t be solved by legacy regulatory tooling.
Model engineering (e.g. live steam) Woodworking? Small carpentry (e.g. non-critical structures, swings, playhouses, most decks (I think these usually require inspection, but not a liscence to actually build), chicken coops? I think in most places you can still build your own house, but it requires inspections.
Licensing computer engineer and scientist - I was wondering when this idea would surface. I mean, that is a great way to strengthen monopolies and consolidate existing players. I didn't expect such a suggestion would come from a Freebsd core developer.
Licensing is about compliance. It helps better control who has access to a certain set of skills, and who can make a living off such skills.
License could require you to be certified for certain technologies, which mean whoever has the best lobbying power win (Hint, it's not Freebsd). It's a great way to keep market shares for specific interests. Not sure how this is good for the industry.
Licensing means you can put barriers to entry for specific demographics (ineligible if born in a specific country...)
Licensing means you can create an entire business model just around licensing fees and licensing bodies, which usually mean some people are left off the game.
You want to increase professional liability and overall responsibility, they are other ways.
First, you have certifications. They already exist and can give ad-hoc solutions for some specific niches, and is the closest that we have to a license today. You can create a mechanism for someone to lose their certification if they commit a professional fault (even if this would totally be used in some case for internal politics and pressuring people in doing they don't want, irrelevant of any actual professional issues).
Second, you have transparency. Company can publish internal explanations of any disaster and if people are terminated because of it, they can make this public. Not that I like the idea... but it is a middle ground - where others are given an opportunity to decide if they to take the risk hire people with public failures, while not removing someone from exercising one's profession because some project went to hell and someone made mistakes.
Anyway, overall, I get his point that he want more responsible engineers on the job, but gatekeeping an industry with licensing sounds like a recipe for an even worse shit show.
Licensing is about compliance. It helps better control who has access to a certain set of skills, and who can make a living off such skills.
License could require you to be certified for certain technologies, which mean whoever has the best lobbying power win (Hint, it's not Freebsd). It's a great way to keep market shares for specific interests. Not sure how this is good for the industry.
Licensing means you can put barriers to entry for specific demographics (ineligible if born in a specific country...)
Licensing means you can create an entire business model just around licensing fees and licensing bodies, which usually mean some people are left off the game.
You want to increase professional liability and overall responsibility, they are other ways.
First, you have certifications. They already exist and can give ad-hoc solutions for some specific niches, and is the closest that we have to a license today. You can create a mechanism for someone to lose their certification if they commit a professional fault (even if this would totally be used in some case for internal politics and pressuring people in doing they don't want, irrelevant of any actual professional issues).
Second, you have transparency. Company can publish internal explanations of any disaster and if people are terminated because of it, they can make this public. Not that I like the idea... but it is a middle ground - where others are given an opportunity to decide if they to take the risk hire people with public failures, while not removing someone from exercising one's profession because some project went to hell and someone made mistakes.
Anyway, overall, I get his point that he want more responsible engineers on the job, but gatekeeping an industry with licensing sounds like a recipe for an even worse shit show.
As a side note - from a separate post today on HN: https://news.ycombinator.com/item?id=28730190 - should we to apply the same logic, then we'd need a license to be the CEO of a company.
[deleted]
The RBQ which is the agency in charge of making sure the rules are respected for construction, removed all their licenses yesterday.
It took years, but finally people will no longer suffer from crooked builders.
Here is the news. It's in french. https://ici.radio-canada.ca/nouvelle/1828502/construction-re...
I wish there was some kind of agency in charge of penalizing crooked software companies which are known for years to screw businesses. It will take time, but we will get there.