The headline contradicts the conclusion. The software industry offers the exact professionally licensed engineers who are subject to the liabilities spoken of. In reality, is the professional engineering bodies who have not given reason for buyers to want to pay extra for those people. I'm not sure this article improves on that situation, only offering some fuzzy notion that bad things could happen to a business organization, much the same as what will happen if budgets are stretched paying for PEs.
>The time is way overdue for IT engineers to be subject to professional liability, like almost every other engineering profession. Before you tell me that is impossible, please study how the very same thing happened with electricity, planes, cranes, trains, ships, automobiles, lifts, food processing, buildings, and, for that matter, driving a car.
How will that solve the problem? Even if we were able to agree on a profession, that people could read and sign on to, would it help?
Everything is build on sand. There are zero operating systems that can stand for a year without patching in the face of contact with the internet.
Blaming system administrators, programmers, or users isn't going to help fix the fundamental design flaw at the root of our software.
We need operating systems that are provably secure upon which to build the rest. Then we can apply the principle of least privilege, and a series of security policies to build upon that.
In the mean while, there is one fundamental tool which is under utilized, the data diode.[1] With such a device, it would be possible to monitor a system from the outside world (via the internet, etc.). A polling loop sends data out in a continuous manner (with forward error correction), and a matching server receives the data, checks for errors, an then makes it available to the outside world.
You can also use data diodes to allow submission of information from the world, without the danger of exfiltration. Such a system might have helped prevent the OPM breach of 2015 if the database were only allowed to be added, and never queried via network.[2]
> There are zero operating systems that can stand for a year without patching in the face of contact with the internet.
Similarly, there are also zero buildings, bridges, aircraft, etc. that can realistically withstand attacks of humans despite being built by engineers who have taken on the liability. A sufficiently powerful bomb will win every time. It seems a bit strange to want to hold software to a higher standard here.
>A sufficiently powerful bomb will win every time. It seems a bit strange to want to hold software to a higher standard here.
A brick fortification built in the 1800s will always offer some defense from small arms fire. You can't cause that fort to attack all other nearby forts. The side effects of the fort are locally limited.
A computer that allows unauthorized infiltration of command (not just denial of service) can be used as an offensive weapon by anyone (or any bot) anywhere. [Edit]It's like building your fort out of crates of explosives, instead of bricks.[/Edit] The side effects of a computer are not locally limited.
I think it is only rational to require a standard appropriate with such a radically different set of side-effects.
> You can't cause that fort to attack all other nearby forts.
Why not? Clever blast planning could send the shrapnel from one fort into another, seeing one fort carry out an attack on other forts. What motivated people can come up with is a complete unknown, and therefore incongruent with engineering, which requires a set of known and predictable states.
I think this shows one of the weaknesses of the building analogy.
Buildings might stand up to basic civilian attacks usually, but probably most aren't built to stay up in the face of the sort of things that a professional military can bring along -- artillery, etc.
In software, where things can be copied essentially for free, there's no need to have a military industrial complex to mass produce artillery if you want to go around blowing things up. Tools from intelligence agencies leak, and then can be copied infinitely, eventually trickling down to script kiddies. There's a blurry line between intelligence services and criminal organizations in some countries. There's a blurry line between military spying and corporate espionage in others.
A world where some teenager could buy nearly-current tanks from a guy their weed dealer knew would not have many tall buildings, I think.
> In the mean while, there is one fundamental tool which is under utilized, the data diode.[1] With such a device, it would be possible to monitor a system from the outside world (via the internet, etc.). A polling loop sends data out in a continuous manner (with forward error correction), and a matching server receives the data, checks for errors, an then makes it available to the outside world.
Something like that was implemented at Amazon in the early days using a modified serial cable that prevented credit card information from ever exiting the payment system even if the web servers were compromised.
Every one of these complaints always misses the salient failure of the analogy: do you expect your bridge or your gas line or your house's electrical layout (once it's installed) to be changed every month or quarter to handle new load, produce different results, or even change its feature set? No - these things are planned for and built to do exactly and only the thing they were first designed for. Heck, you can even throw certain software into that mix like medical device firmware. The software industry is doing exactly what people want out of it: becoming highly flexible to individual business and consumer needs in sophisticated customized interactions.
Those of us who write it are trying as hard as we can to impose sensible and reusable structure on things, but the public wants constant innovation. Not the same "heat my house when I plus this in" demand they had 50 years ago that would have given us the stability to focus on standards, safety, and efficiency. We're doing the best we can.
Hmmm, I think TFA misses the fact that software engineering, isn't really engineering any more. We don't develop code that gets deployed and stays in place (well, maybe in embedded systems, but even those are getting IoT'ed).
Modern software is a service: it gets updated all the time, it's "hired to do a job" rather than perform a specific function. The latter is finite, controllable and could potentially be certified as an engineering product. The former relies on professional codes (and yes liability as well) to make sure that the service is acceptable.
All that is to say that the proper metaphor isn't licensing as for civil engineering or telco networks but akin to licensing for professional services, like medicine, accounting or law.
Which means different tiers of service, different expectations and yes much different compensation/service fees. But to get there we have to stop talking about 'engineering' as the correct framework. We're closer to lawyers or nurses...
If you think of a software system as a manufacturing plant, you can make some pretty straight analogs to other engineering functions. I know plenty of engineers who work at auto plants, power plants, or the like whose jobs are much more traditionally engineering and look a lot like what a modern software job on a distributed system look like. The core business is modeled and run through the software. Things break and will need modification over time, so the engineers are always present. It's not that software is outgrowing engineering. It's that software is growing to look more like other professional engineering disciplines.
The businesses we support are predominantly the professional services you list, so maybe a mental model of a professional services factory is where we're headed? You're certainly not wrong that software engineers need to be comfortable in those environments, but I suspect there's a bit of motivated reasoning among those who see our career becoming more like doctors, lawyers, and accountants, though I would love that to be the case. If anything, those professional jobs are looking more like engineering jobs over time as their own moats have been eroded. Aren't the software engineers coming along to make those professional careers look less special? I'm watching all the local dentist and optometrist offices get purchased up by chains instead of a new generation of small business owners. I'm not aware of another profession which has risen to those ranks, so I suspect their current place is merely a historical relic which is passing.
Not to mention that security seems to be his primary concern. Professional engineers working on buildings aren't liable for someone who decides to take a bulldozer to it to find its weakness, so it would be equally unreasonable for engineers to be liable for someone taking a 'virtual bulldozer' to software to find its weaknesses. What humans can dream up is an unknown and unpredictable quantity, which is incompatible with engineering.
When it comes to software operating within known constraints, we're usually pretty good at delivering. The software in your car, for example, may be full of security holes if a human decides to attack it, but as far as working within the known environment, it is likely to work just fine and as expected. That is all we would expect of a professional engineer.
If you want to stop people from driving bulldozers into your buildings, you're going to have to look beyond the engineers. That is not their area of expertise.
> Professional engineers working on buildings aren't liable for someone who decides to take a bulldozer to it to find its weakness, (...)
Actually, they are.
Engineers are tasked with designing safe structures taking into account a bunch of failure modes, not only those that involve safety but also usability.
These failure modes are even covered in standards, and engineers who fail to design projects which are safe under these scenarios are held liable both civil and criminally.
There's a limit to these things. Residential houses are not designed to withstand machine gun fires. Or a novel chemical, or even just an uncommon but nasty one.
> "Residential houses are not designed to withstand machine gun fires."
If machine gun fire were a daily occurrence for residential houses, they would be. Every other common occurrence that occurs to residential houses, whether it's fire hazards, snow load on the roof, earthquake protection, etc. is part of the design consideration for residential houses.
The fact that software _predictably_ gets attacked when placed online is exactly what means that developers can't shrug their shoulders and pretend it's an unforeseen event.
Except machine gun fire is consistent. Say you were to plan against guerilla warfare with various arms and various tactics that evolve each year because there's an arms marketplace. Could you?
How often do the people who pay for the software plan for that in their budgeting? Supposed I were to say this software has been pentested before release and it'll cost this much extra. How many people are paying for that? How many people will pay for it to be pentested each year for new vulnerabilities?
They're not missing doors and locks; the auth layer exists, but it's not without weakness.
Most residential doors I've seen can't even stop someone with a credit card or metal shim, unless they have and actually use the deadbolt. The vast majority can be picked with ease if you have experience (and hackers typically do). You can also just check windows, since most people don't lock them.
If you don't have to leave the door intact, there's a billion ways to get in. You can ram through the door, since they're not terribly thick. You can drill out the locks. You can saw through the hinges and/or the bolts. If you really don't care, any number of guns can remove the locks or hinges.
An angle grinder will neatly handle any safe you're likely to find inside.
When you're deploying something to the warzone, there are many unknown unknowns that affect the outcome. Things get predictably attacked and the defense can get unpredictably destroyed.
Firearms and tactics evolve over time and very few things can really be blamed on the engineer. The rules for PE are also based on evidence of due diligence on known problems rather than absolute liability, because nobody knows everything that could happen, and can't cover all possible failures. You should read up on how tanks are destroyed or stopped in inventive ways in guerilla warfare, such as in the ongoing Ukraine conflict (it's not just failure of maintenance) or in Vietnam war.
I also don't understand why you could selectively skip the part about novel chemicals.
I suspect the point is more that PEs and architects are supposed to deal with a known set of threat models, most of which ARE NOT nation states deploying dedicated teams to getting inside the building. We don't harden every building for military attack.
Software, on the other had is expected to stand up to being exposed to nation state level threats that we know about, as well those in the future that we don't know about.
We can't get mad that Sony was hacked by North Korea in the same way that we wouldn't be mad at the engineers if the studio building burnt down after being bombed by the North Koreans.
The buildings in the path of Killdozer[1] didn't stand up. The machine penetrated them with ease. Are the engineers who designed them in jail now, or what? Or was it understood that designing a building to not give way to the fate of a rogue bulldozer was not a necessary feature of the original design because at some point you have to accept that a determined enough human will find a way in no matter what? Even if you do design it to withstand a bulldozer, the determined human will just bring in something more powerful. The determined human is clever and unpredictable, which doesn't realistically fit the engineering model of working within known constraints.
I would offer that there is good reason why building security (e.g. police) is its own profession, not a traditional engineering discipline.
In a way, most of my favorite pieces of software are not that. MediaMonkey 4, Ynab classic both stopped getting updates, DirectoryOpus has only been getting fixes and scripting additions for years. Yet they are my favorites and better (ynab, MM) than their successors.
The service part seems more like greed than something I want (in many cases, certainty not all)
Couldn't agree more. Software COULD just solve a problem and then get out of your way, but because we're stuck in a world where MRR is king people are forced into making SaaS trash where the incentives aren't aligned to deliver what technology is capable of. Photoshop/Illustrator was less buggy years ago, and consequently I now just use ancient pirated versions. I feel zero percent bad about this, I'd buy em if I could. Same with Windows, LTSC frozen out of updates is an infinitely better experience than whatever monstrosity Microsoft is peddling these days. Total Commander has been solving the same problems the exact same way perfectly well for 20+ years.
I love innovation as much as the next guy, there are constantly legitimately great advancements in software. That, however is not the same thing as a constant drive for change for changes sake. I want to pay a fair price for tools I can rely on today, not nebulous promises of future improvements that result in tools and processes being broken from time to time. It's not worth it. It's not a good trade-off. The idea that I can have something working perfectly fine and have it suddenly break the next day through no fault of my own is fucking abhorrent. I'm not here for it.
I've written services at startups that I know were in place 10+ years later. I'd be surprised if the majority of my code was still powering them, but never the less, when you solve a hard problem well - software has quite a bit of staying power. You see similar trends in the PostgreSQL code base where critical code pieces/structures date back to 1991 in some cases.
I'd doubt that a professional certification is needed for practitioners of software, but I could see merit in a certification body for software products. There are software products used in critical use cases, where the standard of practice for security, operations, or testing is insufficient for the desired use. As a client of such products, I might choose the "certified" version over the un-certified in a space where I don't believe feature velocity matters.
The problem with any of this would be making a compliance regime that didn't boil down to a boring ineffective process.
There are also physical products that are un-engineered, such as pretty much any one-off made by a craftsman or DIY'er, but engineering is still engineering. The unique thing about software is that an unlimited number of craftsmen and DIY'ers can be brought together to make things of limitless complexity.
I understand where you are coming from, but this is not completely true. We often build physical infrastructure & buildings that need to evolve and change over time. This sometimes leads to over-building and often over-engineering but the biggest difference is we don't usually design & build software to true engineering standards. We move quick and break stuff, fix it after release, waterfall is outdated and maligned, nobody is held responsible for catastrophic failure.
Most of us are NOT engineers. Even less build software as engineers.
This is my pet peeve too. They also completely ignore the fact that humans have been building physical structures for ~10,000 years where as software industry is less than 100 year old. Give it time to mature.
> do you expect your bridge or your gas line or your house's electrical layout (once it's installed) to be changed every month or quarter to handle new load, produce different results, or even change its feature set?
More than that, the reason most tech companies don't have a salaried plumber is because most tech companies don't rely on a plumber to try to increase the revenue of their core business model.
Really nice to see comments like this, often HN feels like software engineers attacking other software engineers with zero empathy for the fact that they're in the exact same position.
Most engineers don't work on static systems. They work supporting things like manufacturing plants, electrical plants, and working on infrastructure which degrades and requires repairs over time. Engineers aren't only involved in the creational part. To me, the software industry is looking more like professional engineering over time and less like a science research project.
Aren't the gas and electrical lines akin to some core capabilities of the system? I have yet to find a (web project) that doesn't need auth, eventing, logging, etc. I don't expect those to change how they work frequently, just line the guts of the building.
To keep with the metaphor, I DO expect to plug an appliance in, though. Or that a room could be used for another purpose. Obviously changing from an office to a commercial kitchen is a major change but if that's what somebody wants to spend their money to do...
So I guess my thought is, "software engineering" and "engineering" are very broad. I actually think software challenges are not so unique. My experience has been that many people lack intuition about the software in question. Most people live in a building of some kind and if they asked for only Brawndo in the water pipes, it would be easy to convince them of how short sighted that is (or they wouldn't even ask). With software I feel like there's still some expectation of magic and zero friction just because it doesn't take a jackhammer to move a wall.
Okay, the analogy is not exact, and some software is genuinely different. That's fine. But what I don't understand is why you and others in this response claim that "it must be okay because people purchase it that way" is a legitimate argument in this context.
The idea that the markets can figure out how to build reliable and efficient infrastructure is contrary to evidence, theory or intuition. The actors are vastly asymmetric, information is hard to get by, risks hard to evaluate and judge, many infrastructures are natural monopolies, etc... And a large part of code in companies _is_ infrastructure.
In this type of context, people who would individually make shitty purchasing decisions generally support laws that support them in making better decisions (or in not having to make decisions). You do not want to evaluate whether saving 2$ on rent is worth the increased fire hazard of not having adequate fireproofing in the insulation.
You sure as hell wouldn't want the company to not be liable if they just installed the cheapest shit they could find and the building does burn down.
> You sure as hell wouldn't want the company to not be liable if they just installed the cheapest shit they could find and the building does burn down.
What? You mean like a company installing bad cladding that burns really easily, then refusing to take responsibility when a load of people's homes burn down and some are killed? Of course, that would never happen in the real world... ahem.
Seems less true to me than "VCs, entrepeneurs, middle management and MBAs want constant innovation", which is to say "capitalists want constant innovation". The constant churn is a sales-driven impulse to capture more of the market, and it's organizations throwing endless (and mostly pointless) change in order to move a few more units or renew a few more subscriptions. It's not the consumers who think software isn't finished, it's the people selling it.
Think about Office 97 and what you do today. Has anything added to MS Office since then mattered at a wide scale?
Correct, the problem is capitalism and intellectual property. The capitalist system simply has no way of dealing with the fact that writing documents or spreadsheets is a thing we can more or less solve once and give to everyone for free at no additional cost. That's the reality of the situation, the problem is the idea of ownership as applied to things that can be infinitely duplicated at no cost. It's a growing disconnect between reality and the capitalist economy. I have no solution, but I know it doesn't make sense to own intangibles in the way copyright/patents/intellectual property and other bullshit like nfts are attempting to impose on a digital world the reality of which is fundamentally different from the tangible one. Creating artificial scarcity is wrong.
Capitalists want money, and they usually do whatever makes money. In software, constant churn and superficial redesign seems to make more money than reliability, security, and core improvements.
Be that as it may, Office 365/Teams are probably new since Office 97.
Arguably it wasn't a Microsoft innovation per se and was a response to Google Docs/Slack/etc. but internet/cloud/web-based collaborative editing integrated with group chat, video conferencing, and document sharing are probably new features since Office 97 that are somewhat useful, even if they don't work particularly well.
Er, no. The public wants software that “just works”. Everybody hates the new normal of eternal beta, or when their familiar and working software is changed to look or function differently, more often than not also removing existing conveniences and features.
As somebody who switched careers from construction to software development, I disagree with your criticism. Systems in a house are largely decoupled and easily extensible and modular. It's a routing affair to add a room or second floor. You can replace all the plumbing in a house without touching the electrical. You can easily upgrade an electrical service and add more circuits and outlets to an old house. The nature of stud framing makes it relatively trivial to run ethernet cable through a 70 year old home, or replace ancient single pane windows with the latest triple pane offering. You can swap out your dumb lightswitch for the latest wifi connected smart home nonsense, all without disturbing anything else in the house.
I also disagree that "we're doing the best we can." We're building monstrously complex systems because it pads our resumes, not because it actually solves real problems.
On what earth does "the public" wants innovations? The way it works is the tech industry has to work hard to sell innovations. Yes once the innovation is in, it creates a backward pressure for the rest of the industry.
If there was a transparent way to show pros and cons of these "innovations", the public might not be very keen. In certain areas (2D UI development) it's like the food industry where there is nothing left to innovate, they still keep making new, "better" (good looking but more toxic and addictive) food to sell.
There's a SAAS I use some at work that is just a pile of shit that is designed to be marketable. Everywhere you look there are broken leaky abstractions.
They are always really enthusiastic and positive though.
- On one hand, professional liability would indeed be a good thing for overall reliability of our software systems. A "code" for offering software products to citizens would be a good thing. The GDPR is a good step in the right direction for privacy concerns, but there are many other types of concerns that could be covered.
- On the other hand, most of the "real" problems in infrastructure software come from adversarial action. Most software systems run more or less fine by themselves, from a professional liability standpoint. Adversarial action is not usually covered by "professional liability". For example, nobody blames the architects of the Azovstal plant that the steel furnaces couldn't stand up to sustained artillery bombardment.
- Despite all the talk about how critical software systems are these days, 99% of systems out there is the equivalent of a garden shed and nobody would care if it falls over. Certainly the shed in my own garden would not survive a proper hurricane, but that is OK because a. we don't really get hurricanes here and b. the cost to completely rebuild it would be much lower than bringing it up to hurricane standards. Even Maersk, which is surely not a small target, managed to survive a full blown ransomware hit just fine. (By which I mean, they took a fairly large hit financially but nobody died and no ships sank. By and large all vessels even reached their destination on time) Their IT had to work a lot of overtime for sure, but "the system" is not as vulnerable as people like to claim.
So what to do? I would not mind some form of legally mandated checklist to follow that would be mandatory for any company offering services on the internet, but at the same time I don't think it would be very effective in countering the worst threats and I also don't think it would be proportionate for most companies.
The shed's a strawman. How do we handle hurricane damage and other "acts of god?" Not in court, but with insurers. Do insurers currently insure properties with sheds? Yes. Do they insure shabby sheds against hurricanes? Maybe - it's up to them and I'm sure they can figure out if the odds would pay off for them.
If your shed exploded into millions of shards of glass when struck by high wind that would be a different story. Or if it spread toxic chemicals all over your neighborhood. Or if it caught fire easily and the fire could spread to other buildings. Who would have thought sheds would make such wonderful metaphors?
I think you are missing the point I was trying to make with my shed. It's a flimsy building that was definitely not "Engineered" with a capital E. It was slapped together by some carpenters apprentice in much the same way that most software is slapped together without much calculation or planning, and that is fine because it's just a shed. The hurricane is not very relevant to the argument, just that there is no building code regulating the shed.
My point in the GP was that most software (even in the biggest of enterprises) is more like a shed than a skyscraper: not very well Engineered and also not very critical. Even Maersk can apparently survive just fine without their logistics planning software for over two weeks. What would be the appropriate level of regulation for software that is apparently not all that critical? I think the appropriate level of regulation for most software would be extremely low, because not much is at stake.
"The pretence that corporations are necessary for the better government of the trade, is without any foundation. The real and effectual discipline which is exercised over a workman, is not that of his corporation, but that of his customers. It is the fear of losing their employment which restrains his frauds and corrects his negligence. An exclusive corporation necessarily weakens the force of this discipline. A particular set of workmen must then be employed, let them behave well or ill. It is upon this account that, in many large incorporated towns, no tolerable workmen are to be found, even in some of the most necessary trades. If you would have your work tolerably executed, it must be done in the suburbs, where the workmen, having no exclusive privilege, have nothing but their character to depend upon, and you must then smuggle it into the town as well as you can."
This was good advice in 1700's Kirkcaldy. Doesn't work so well in a globalized marketplace and with products where by the time a defect has manifested, the vendor is long gone.
Can't agree more. I've been saying for years that we should have some professionalism added to the industry.
It doesn't mean that everyone who writes code must be licensed. But to determine if software is fit for purpose you must be. Liability is important and software doesn't have to threaten life and limb to benefit from it. Many engineering professions also protect property and business interests (along with life and limb).
What I hope such a system would provide is a means to prevent companies from cutting corners for the sake of profits and give engineers the right to say what is fit for purpose. Too many breaches that have cost economies too much money happen because IT is incentivized to release now and fix it later. Then hundreds of thousands of peoples' financial details are leaked or their pensions disappear. And the current system of liabilities don't protect the end users or dissuade the software industry from continuing on this destructive course.
We also don't account for externalities well. Consider how many years PoW crypto mining has been going on, growing, and forcing new coal plants to open to keep up with demand. People in rich countries don't care because it's not happening in their backyard and it is promising to make some of them rich. That happened because we have no social safeguards against bad technology harming the environment/society/etc. You can write a software service that exists to use up as much energy as possible and you will never face any consequences for the damage caused.
We barely slap people on the wrist for organized crime let alone corporate crime, negligence, etc.
We're not talking about your high school web project here. We don't have to prevent people from learning and building things on their own. I just think we need to prevent companies from rolling the dice with our future and let the folks who know what they're doing run the show.
I recently got professionally qualified as a software engineer with a capital E. I'm still the same regular programmer I ever was! Not sure a piece of paper really solves anything.
I don't think we have the legal frameworks set up yet. Even where I'm from the professional engineering guilds are trying to move in on software but the enforcement is too weak to be useful.
In Canada it varies by province and most of them protect, 'Professional Engineer'. Some are going after 'Engineer' (in the software context) entirely but this had been tested in the 90s and didn't work.
I mean that, at least in Canada, there aren't strong legal frameworks that require P.Eng to sign off on projects, to manage development teams, the protect their jobs, liability, etc.
So far from others who've received the designation it's mostly "just paper" for now.
It shouldn't add any capability on your side. But it should help other people distinguish between you and someone who couldn't pass whatever test, right?
Of course we don't really know how well that test maps to real world competency!
> What I hope such a system would provide is a means to prevent companies from cutting corners for the sake of profits and give engineers the right to say what is fit for purpose. Too many breaches that have cost economies too much money happen because IT is incentivized to release now and fix it later.
I find that, at companies that tend to beat market expectations it's already like that. You can always tell whether they consider engineering a cost center or a core part of the business. It's no accident that the CEOs of the majority of fortunes 5 are engineers...
The author makes a decent case that some sort of licensing should exist for some types of software development at some point in the future. But the devil is in the details, and the merit of the licensing process needs to be proven.
A lot of regulators are valuable but we've also got a lot running around with red tape and power trips that they didn't earn. We're extracting thousands of dollars from low-income minorities for hairstylist licenses that benefit no one. We've got engineering boards punishing people for publicly (and correctly) disputing the math of red light timing. There's too much abuse.
Regulation isn't just one way. Regulators need to be held accountable too.
It's especially interesting that the author has open source experience, and decides to put a company that went through a ransomware attack as a way of discussing liability.
Imagine for a second that the ransomware attack comes via an attack vector because, say, there's a security bug in Spring, giant Java library/ecosystem, that almost everyone pays zero for. Then imagine that this is in a world where the engineer is liable. How does this play out?
First, you could claim that the bug is in OSS Spring, and that they can't waive liability. In that circumstance, I'd be surprised if OSS continued existing: You get very little for your contribution in comparison to the liability risk. It's the same for corporate sponsored OSS: Imagine telling your company's counsel that you want to open source a library that is unrelated to the core of your business. Never. So this either has cataclysmic consequences to OSS, or we get to say that anyone making OSS's legal disclaimers are legally binding.
So what happens instead? Anyone building applications for a company is responsible for all the bugs in the libraries they chose. OSS will still be mostly poisoned by this. Imagine the fun of taking liability, as some kind of signing engineer, for a half a million lines. And those lines are almost sure to have some vulnerabilities: It's just that we don't know of them yet, and you need patching forever, just like you do today. And along with the patch, we'll have great discussions about who brought in the patch that introduced the vulnerability.
Note that this is especially fun in a world where security is covered by this. It's one thing to assume that ones code to control a car will not accelerate without bounds, risking deaths to the passenger. Then your design is narrow, and can have a semblance of good testing. Testing that your code cannot be used as part of a security vulnerability is testing a far wider field of possible inputs.
Either way we slice this, all I see is the world building a whole lot less software, because the dangers of writing it make all kinds of products dangerous. We either move to a world where a lot of code is shared and owned by a few companies that take all the liability, and hit major trouble whenever they have a vulnerability, because suddenly they are to blame for possibly millions of breaches, or a world where we share very little code, we evaluate it more thoroughly, and we hope nobody pays attention. I bet my libraries to handle certificates would be worse than the ones experts built today, but I could hope nobody examines them.
But yes, as others say, the world could do this right now: We can hire a firm to build something and take the liability for us. It's just that, in general, we don't, because they don't give us anything more secure, or better: mostly more expensive. Instead we might just buy insurance, and hope we don't have too much of a counter-party risk.
If we cut security vulnerabilities out of the equation, maybe there is a good defense that the world the author describes might be different, but not worse than the one we live in today. But with security? Tough.
The finishing paragraph addresses exactly your point:
> As with software product liability, the astute reader is apt to exclaim, "This will be the end of IT as we know it!" Again, my considered response is, "Yes, please, that is precisely my point!"
People assume software is just like engineering a bridge, but it isn't. Software changes all the time, due to market needs, due to attacks from the outside or inside, due to legal changes, due to executives who want to be promoted, due to technological changes, due to etc, etc. Bridges do not change, as gravity and wind and temperature and chemistry and physics are in the real world while our software exists in a world of our making, generally built in myriads of layers, often from multiple vendors, and have to interoperate with myriads more other worlds that are also continuously changing over networks which we may not have any control of.
Since I started in the early 80's every generation thinks they can standardize things, license programming, make things from perfect reusable parts that work perfectly, and generally turn programming into recipes. Every generation fails.
In reality software is a mess because none of those things are possible because complexity is inherent in what we do, and what is expected of us, and there has never been any way to satisfy everything we are asked to do with some magical silver bullshit, err, bullet.
Even if you wanted software "Professional Engineers" to be a thing, how would you even do that, with 100's of programming languages, operating systems, software environments and industries all with different needs, and in an industry that changes every single day. Bridges have been built for thousands of years, software has changed radically and continuously since I started in 1981. As soon as you defined some standard to test against, it would be obsolete.
I could complain about software endlessly and I came here to do it, but the comments discussing the analogy breakdown between software and bridge engineering made me wonder - is bridge engineering really so staid and rote? I've seen some beautiful bridges built in the last few decades and it makes me wonder if they get to play around with design as well.
The appearance of bridges might change but I suspect that the underlying structural components are much better specified than what we have with software.
While I don't know the specifics for bridges, I have seen the specifics for the joist industry (those metal rails with Ws inside them that you see when you look up at the ceiling in a Walmart).
There is some design work that an engineer needs to do for any given job. However, they pick the type of joist, material, and wield (etc) based on a book that publishes weight tolerances. And those numbers come from someone taking a joist out someplace and dumping weights on it until it collapses.
We just can't do the same thing with software. It's not even clear what kind of weight we would be dumping on software. Human comprehensibility? How do you measure that?
Most bridge designing is reasonably staid (not as much as buildings, but not as neophilic as software by a huge margin). But some bridges get very unusual designs, either by necessity or aesthetic reasons, and the people that can design those command a high price premium for their work.
If all software specifications were as finite as bridge specifications you would see a lot better failure rates.
A bridge is deployed in a single instance, in a single environment with a specific type and quantity of traffic. Everything about what a bridge does is known and quantified. As a rather direct example, look at the software that runs traffic lights; doesn't really ever fail, every possible state is covered, and as a result we trust with our life that when our light is green, the cross-traffic is red.
There's plenty of software that is as reliable as bridges. On the other hand there's a lot of professional engineering that I would trust far less than a web app. Things like high-end cars, sports equipment, rockets, etc. are all signed off by professional engineers but have an incredibly high failure rate.
The author's analogy is bad. On the software side, he's talking mainly about security. On the other side, he's talking mainly about build quality. But those two things are not really the same. No homebuilder pays liability if a criminal breaks into your house and steals your stuff. That's security and has nothing to do with build quality. If someone steals your car, does the auto manufacturer pay liability? No.
Computer security is definitely a problem. But this argument by analogy simply doesn't work. Moreover, non-computer security is a problem too. (School shootings, anyone?) Anyway, talking about toilets and whether they work isn't helpful at all in this case.
Since every other blue collar profession is regulated and only certified individuals can practice it, we will probably get the same at some point in time.
Because we're still stumbling on what is and isn't a "bad practice" while companies continue to gaslight the developer population and a few consultants and spokesmen have endless discussions on what should and shouldn't happen.
Ergo, there's no incentive to fix it, and every incentive to keep it broken.
Standardization of threads started between private companies around the year 1800, and continued on mixed in with a bunch of other "competing" private company standards. Sick of the lack of a unified standard, William Sellers submitted a paper in 1864 proposing one standard based on an already popular form. Eventually the USG adopted this as a requirement in government contracts, was adopted as United States Standard thread, and later Unified Thread Standard. The standard is maintained by the American Society of Mechanical Engineers and American National Standards Institute.
- As noted at Wikipedia, wartime mechanisation and the requirements for standard parts to be provided for the new high technology of motorised transport, armour, and aircraft, drove further standardisation.
- The noted socialist and collectivist,[1] Herbert Hoover, provided the final push toward standardisation of weights, measures, and engineering components, as Secretary of Commerce.
It turns out that military needs and government legal authority and purchasing power can do much to promote standardisation which the free market cannot.
A subsequent case emerged during the Vietnam War during which the US Navy, a/k/a the transport and logistics arm of the US military forces, faced a critical problem in delivering supplies and materiel to very underdeveloped South Vietnamese ports. Though there'd been multiple attempts to standardise shipping around a single container size, this proved to be the ultimate nudge which established the TFU, or twenty-foot unit standard. (Now largely seen in its doubled form, the 40-foot shipping container.)
It's not just that, it's more born out of ego. Every idiot who can write a CRUD app thinks they're Zuckerberg building the next big thing. Unless you're working in specialized arenas of FAANG, you're not, and that's okay.
Those of us experienced in DevOps have been trying to set standards for repo/project structure, deployments, etc. for quite a while, but it seems like every developer has their own idea of what they did the first time they read a blog post about "how to build X app" and then will use a different structure after they consume their next Medium article. Or, even better, they're been "doing it this way for 10 years", or "I heard Facebook/Amazon, etc. does X".
We're currently in the stage when we create all of our own bespoke connectors - glue code. RESTful interfaces are an attempt at solving part of the problem but they still require a lot of hand fiddling to make them work.
While mechanical connectors have existed for millennia, standardized connectors were a set of fairly recent innovations from the industrial revolution [1], with notable standardizations like unified thread as recent as post-WWII. So they're both new and took time for all of the standardizations to settle to what we have now. And the state of mechanical connectors is not static. There is constant innovation. Consider medical, military, and other applications with special demands.
Seen in that light, software is very rapidly standardizing. Like everyone else here, I feel your pain, though.
- instruction sets (e.g. x86, ARM)
- 8 bit bytes (though there are two byte orders)
- floating point formats and operations
- programming languages (Java, JavaScript, C++...)
- standard libraries (Java SE, libc, stl...)
- OS APIs (Win32, POSIX...)
- network protocols (HTTP, TLS, TCP/IP, BGP...)
- data formats (HTML, XML, JSON, MIME, protobufs...)
However the design complexity of software, with potentially dozens of levels of abstractions and millions of lines of code, isn't greatly reduced by using these standard nuts and bolts.
Jesus Christ, it's like he's read my mind. He's hit the nail with a laser beam. Software continues to be incompetent because there are no incentives to make it competent. We need to hold people liable or they will keep acting like "craftspeople" while building the Sears Tower.
On the one hand, the problem he discusses is entirely real, and he does not exaggerate the scale of the issue.
It is much like medicine in the time of the "four humours". The state of medicine then was a real problem, but if you were to have instituted licensing and professionalisation requirements at that point, it would largely freeze into place a bad situation. The other industries with licensing, have established a good, safe way of doing things. Software has no good, safe way of doing things to establish as code, and teach to new practitioners. I do not exaggerate, either.
On the other hand, what he suggests as a solution, would require that innovation be slowed by at least one, probably two orders of magnitude. Any nation which did _not_ do this, would quickly sprint ahead of those who did, and they would quickly be able to overwhelm the capabilities of the nations who had professional licensing requirements.
I do. But I think there are benefits to having the FDA (and etc.) provide checks on fraud, wishful thinking, etc. I'm pretty sure that, on balance, it's worth it. If it had been instituted back in the "four humours" times, it would not have been.
Most of medicine seems about 30 years behind. Imagine what one could do with all that progress; how many lives could be saved/improved. I disagree with your calculus.
Traditional engineering can be done by unlicensed persons. It's just that the final design must be signed off by a licensed engineer. In the same way, open source software can be contributed to by unlicensed software engineers, but if the system will be used in a production product, it must be signed off by a licensed software engineer.
> if the system will be used in a production product, it must be signed off by a licensed software engineer.
Now I think you're talking about something that large companies could get behind: a massive barrier to market entry and competition that simultaneously neutralizes the threat of open source software while allowing them to sell it.
>It's just that the final design must be signed off by a licensed engineer.
This is a great way to establish a new system to elicit corruption like you get with building permits etc. After all, you don't want your design to be stuck for 9 months waiting for approval, do you?
Dont we want it go go the other way? Dont we want to deregulate quite a few industries?
Software is eating the world for a reason. It is unregulated and unrestricted scientific and technological progress. Why would you want to neuter that?
>The good news is the ransomware attack on Colonial Pipeline in May 2021 probably marks the beginning of the end. Comforting as that might sound, it tells us very little about how that ending will turn out.
I wonder what level of liability would be reasonable when considering the increasing sophistication of these types of hacks. Going back to the bridge analogy, we would hold the licensed engineer responsible if the bridge they built collapsed because of a thunderstorm, but not if the bridge collapsed because a terrorist or rival nation state bombed it. Which of those situations is more analogous to getting hit with ransomeware or some other type of hack?
Say a piece of software from a small company is compromised, should the liability be different if the attacker is some script kiddie versus if it's some hacking group that likely has ties to a foreign intelligence service? Is it reasonable to expect every software company to be able to fend off even the most well-financed attack?
> The time is way overdue for IT engineers to be subject to professional liability, like almost every other engineering profession. Before you tell me that is impossible, please study how the very same thing happened with electricity, planes, cranes, trains, ships, automobiles, lifts, food processing, buildings, and, for that matter, driving a car.
But the people responsible for the Colonial Pipeline are not Software Engineers. SWEs are just workers. Why don't we start to hold the people accountable who extract wealth and give orders? Power and responsibility should go hand in hand.
SWEs _want_ to engineer, make things more performant and secure. They _want_ to say No to unnecessary features. This takes time, trust, money. What about the owners? The board? The executives? They make the decisions, want fast growth, more features, less expenses, software to be a commodity and engineers be interchangeable. Managers and sales people, who buy and sell software packages with fancy names on them to get a promotion, don't do the soul sucking work of integrating with a buzzword driven hodgepodge. Shouldn't they be held accountable first?
With that out of the way...
The example in the article is the Colonial Pipeline ransomware attack. A cyber _attack_. Are bridges, toilets and buildings generally built to withstand arbitrary hostile attacks?
But Lack of understanding of how decisions in the IT industry are made, ridiculous examples and bad analogies aside: I still think there is a good point hidden in there somewhere. Namely that good engineering takes time, investment, auditing, standard processes and a strong technological foundation. But we are not there yet. Nobody is laying the foundation to get us there. It's just iterations upon iterations and layers upon layers, features upon features.
Before we can even start to think about licensing SWEs, we need to start thinking _very_ long term. Much of the SWE effort is funneled into short term monetary gains, while fundamental technologies like OS's common file formats, browsers, firmware and all that stuff is rarely reconsidered and just patched over continuously. The foundations are _inherently_ insecure and the mindset is wrong. Familiarity and productivity often take precedence over simplicity and robustness. Everyone thinks they are entitled to telemetry and other user data and most software is closed source. How do you reason about black boxes? How do you trust them?
Also who will do the licensing? The people who tend to push for these things while shitting on other software practitioners don't inspire much confidence IMO.
> If any science fiction author, famous or obscure, had submitted a story where the plot was "modern IT is a bunch of crap that organized crime exploits for extortion," it would have gotten nowhere
Has Kamp ever read any SciFi published after the '70s? That's a pretty common trope in cyberpunk and subsequent works. Heck, it's a staple of Mr. Robot, hardly a niche production.
> "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization."
If architecture, construction, and civil engineering firms could implement automatically binding license agreements that absolved them of all liability and responsibility, we'd probably see similar results.
126 comments
[ 2.9 ms ] story [ 204 ms ] threadI thought there wasn't any longer any exam for people to take in software engineering to become professionally licensed in the US?
How will that solve the problem? Even if we were able to agree on a profession, that people could read and sign on to, would it help?
Everything is build on sand. There are zero operating systems that can stand for a year without patching in the face of contact with the internet.
Blaming system administrators, programmers, or users isn't going to help fix the fundamental design flaw at the root of our software.
We need operating systems that are provably secure upon which to build the rest. Then we can apply the principle of least privilege, and a series of security policies to build upon that.
In the mean while, there is one fundamental tool which is under utilized, the data diode.[1] With such a device, it would be possible to monitor a system from the outside world (via the internet, etc.). A polling loop sends data out in a continuous manner (with forward error correction), and a matching server receives the data, checks for errors, an then makes it available to the outside world.
You can also use data diodes to allow submission of information from the world, without the danger of exfiltration. Such a system might have helped prevent the OPM breach of 2015 if the database were only allowed to be added, and never queried via network.[2]
1 - https://en.wikipedia.org/wiki/Unidirectional_network
2 - https://en.wikipedia.org/wiki/Office_of_Personnel_Management...
Similarly, there are also zero buildings, bridges, aircraft, etc. that can realistically withstand attacks of humans despite being built by engineers who have taken on the liability. A sufficiently powerful bomb will win every time. It seems a bit strange to want to hold software to a higher standard here.
A brick fortification built in the 1800s will always offer some defense from small arms fire. You can't cause that fort to attack all other nearby forts. The side effects of the fort are locally limited.
A computer that allows unauthorized infiltration of command (not just denial of service) can be used as an offensive weapon by anyone (or any bot) anywhere. [Edit]It's like building your fort out of crates of explosives, instead of bricks.[/Edit] The side effects of a computer are not locally limited.
I think it is only rational to require a standard appropriate with such a radically different set of side-effects.
Why not? Clever blast planning could send the shrapnel from one fort into another, seeing one fort carry out an attack on other forts. What motivated people can come up with is a complete unknown, and therefore incongruent with engineering, which requires a set of known and predictable states.
Buildings might stand up to basic civilian attacks usually, but probably most aren't built to stay up in the face of the sort of things that a professional military can bring along -- artillery, etc.
In software, where things can be copied essentially for free, there's no need to have a military industrial complex to mass produce artillery if you want to go around blowing things up. Tools from intelligence agencies leak, and then can be copied infinitely, eventually trickling down to script kiddies. There's a blurry line between intelligence services and criminal organizations in some countries. There's a blurry line between military spying and corporate espionage in others.
A world where some teenager could buy nearly-current tanks from a guy their weed dealer knew would not have many tall buildings, I think.
Something like that was implemented at Amazon in the early days using a modified serial cable that prevented credit card information from ever exiting the payment system even if the web servers were compromised.
Those of us who write it are trying as hard as we can to impose sensible and reusable structure on things, but the public wants constant innovation. Not the same "heat my house when I plus this in" demand they had 50 years ago that would have given us the stability to focus on standards, safety, and efficiency. We're doing the best we can.
Modern software is a service: it gets updated all the time, it's "hired to do a job" rather than perform a specific function. The latter is finite, controllable and could potentially be certified as an engineering product. The former relies on professional codes (and yes liability as well) to make sure that the service is acceptable.
All that is to say that the proper metaphor isn't licensing as for civil engineering or telco networks but akin to licensing for professional services, like medicine, accounting or law.
Which means different tiers of service, different expectations and yes much different compensation/service fees. But to get there we have to stop talking about 'engineering' as the correct framework. We're closer to lawyers or nurses...
The businesses we support are predominantly the professional services you list, so maybe a mental model of a professional services factory is where we're headed? You're certainly not wrong that software engineers need to be comfortable in those environments, but I suspect there's a bit of motivated reasoning among those who see our career becoming more like doctors, lawyers, and accountants, though I would love that to be the case. If anything, those professional jobs are looking more like engineering jobs over time as their own moats have been eroded. Aren't the software engineers coming along to make those professional careers look less special? I'm watching all the local dentist and optometrist offices get purchased up by chains instead of a new generation of small business owners. I'm not aware of another profession which has risen to those ranks, so I suspect their current place is merely a historical relic which is passing.
When it comes to software operating within known constraints, we're usually pretty good at delivering. The software in your car, for example, may be full of security holes if a human decides to attack it, but as far as working within the known environment, it is likely to work just fine and as expected. That is all we would expect of a professional engineer.
If you want to stop people from driving bulldozers into your buildings, you're going to have to look beyond the engineers. That is not their area of expertise.
Actually, they are.
Engineers are tasked with designing safe structures taking into account a bunch of failure modes, not only those that involve safety but also usability.
These failure modes are even covered in standards, and engineers who fail to design projects which are safe under these scenarios are held liable both civil and criminally.
If machine gun fire were a daily occurrence for residential houses, they would be. Every other common occurrence that occurs to residential houses, whether it's fire hazards, snow load on the roof, earthquake protection, etc. is part of the design consideration for residential houses.
The fact that software _predictably_ gets attacked when placed online is exactly what means that developers can't shrug their shoulders and pretend it's an unforeseen event.
How often do the people who pay for the software plan for that in their budgeting? Supposed I were to say this software has been pentested before release and it'll cost this much extra. How many people are paying for that? How many people will pay for it to be pentested each year for new vulnerabilities?
Most residential doors I've seen can't even stop someone with a credit card or metal shim, unless they have and actually use the deadbolt. The vast majority can be picked with ease if you have experience (and hackers typically do). You can also just check windows, since most people don't lock them.
If you don't have to leave the door intact, there's a billion ways to get in. You can ram through the door, since they're not terribly thick. You can drill out the locks. You can saw through the hinges and/or the bolts. If you really don't care, any number of guns can remove the locks or hinges.
An angle grinder will neatly handle any safe you're likely to find inside.
Firearms and tactics evolve over time and very few things can really be blamed on the engineer. The rules for PE are also based on evidence of due diligence on known problems rather than absolute liability, because nobody knows everything that could happen, and can't cover all possible failures. You should read up on how tanks are destroyed or stopped in inventive ways in guerilla warfare, such as in the ongoing Ukraine conflict (it's not just failure of maintenance) or in Vietnam war.
I also don't understand why you could selectively skip the part about novel chemicals.
Software, on the other had is expected to stand up to being exposed to nation state level threats that we know about, as well those in the future that we don't know about.
We can't get mad that Sony was hacked by North Korea in the same way that we wouldn't be mad at the engineers if the studio building burnt down after being bombed by the North Koreans.
We might, if military attacks were as commonplace, untraceable, and unpunished as online attacks.
I would offer that there is good reason why building security (e.g. police) is its own profession, not a traditional engineering discipline.
[1] https://www.cpr.org/show-segment/this-man-barely-escaped-kil...
They are liable for things like earthquakes and explosions, though, up to some limit:
https://www.fema.gov/emergency-managers/risk-management/eart...
The service part seems more like greed than something I want (in many cases, certainty not all)
I love innovation as much as the next guy, there are constantly legitimately great advancements in software. That, however is not the same thing as a constant drive for change for changes sake. I want to pay a fair price for tools I can rely on today, not nebulous promises of future improvements that result in tools and processes being broken from time to time. It's not worth it. It's not a good trade-off. The idea that I can have something working perfectly fine and have it suddenly break the next day through no fault of my own is fucking abhorrent. I'm not here for it.
I'd doubt that a professional certification is needed for practitioners of software, but I could see merit in a certification body for software products. There are software products used in critical use cases, where the standard of practice for security, operations, or testing is insufficient for the desired use. As a client of such products, I might choose the "certified" version over the un-certified in a space where I don't believe feature velocity matters.
The problem with any of this would be making a compliance regime that didn't boil down to a boring ineffective process.
Most of us are NOT engineers. Even less build software as engineers.
At the same time, there’s also no other industry that operates at a fraction of the speed of this one.
More than that, the reason most tech companies don't have a salaried plumber is because most tech companies don't rely on a plumber to try to increase the revenue of their core business model.
To keep with the metaphor, I DO expect to plug an appliance in, though. Or that a room could be used for another purpose. Obviously changing from an office to a commercial kitchen is a major change but if that's what somebody wants to spend their money to do...
So I guess my thought is, "software engineering" and "engineering" are very broad. I actually think software challenges are not so unique. My experience has been that many people lack intuition about the software in question. Most people live in a building of some kind and if they asked for only Brawndo in the water pipes, it would be easy to convince them of how short sighted that is (or they wouldn't even ask). With software I feel like there's still some expectation of magic and zero friction just because it doesn't take a jackhammer to move a wall.
The idea that the markets can figure out how to build reliable and efficient infrastructure is contrary to evidence, theory or intuition. The actors are vastly asymmetric, information is hard to get by, risks hard to evaluate and judge, many infrastructures are natural monopolies, etc... And a large part of code in companies _is_ infrastructure.
In this type of context, people who would individually make shitty purchasing decisions generally support laws that support them in making better decisions (or in not having to make decisions). You do not want to evaluate whether saving 2$ on rent is worth the increased fire hazard of not having adequate fireproofing in the insulation.
You sure as hell wouldn't want the company to not be liable if they just installed the cheapest shit they could find and the building does burn down.
What? You mean like a company installing bad cladding that burns really easily, then refusing to take responsibility when a load of people's homes burn down and some are killed? Of course, that would never happen in the real world... ahem.
the public wants constant innovation
Seems less true to me than "VCs, entrepeneurs, middle management and MBAs want constant innovation", which is to say "capitalists want constant innovation". The constant churn is a sales-driven impulse to capture more of the market, and it's organizations throwing endless (and mostly pointless) change in order to move a few more units or renew a few more subscriptions. It's not the consumers who think software isn't finished, it's the people selling it.
Think about Office 97 and what you do today. Has anything added to MS Office since then mattered at a wide scale?
Be that as it may, Office 365/Teams are probably new since Office 97.
Arguably it wasn't a Microsoft innovation per se and was a response to Google Docs/Slack/etc. but internet/cloud/web-based collaborative editing integrated with group chat, video conferencing, and document sharing are probably new features since Office 97 that are somewhat useful, even if they don't work particularly well.
Er, no. The public wants software that “just works”. Everybody hates the new normal of eternal beta, or when their familiar and working software is changed to look or function differently, more often than not also removing existing conveniences and features.
I also disagree that "we're doing the best we can." We're building monstrously complex systems because it pads our resumes, not because it actually solves real problems.
On what earth does "the public" wants innovations? The way it works is the tech industry has to work hard to sell innovations. Yes once the innovation is in, it creates a backward pressure for the rest of the industry.
If there was a transparent way to show pros and cons of these "innovations", the public might not be very keen. In certain areas (2D UI development) it's like the food industry where there is nothing left to innovate, they still keep making new, "better" (good looking but more toxic and addictive) food to sell.
They are always really enthusiastic and positive though.
- On one hand, professional liability would indeed be a good thing for overall reliability of our software systems. A "code" for offering software products to citizens would be a good thing. The GDPR is a good step in the right direction for privacy concerns, but there are many other types of concerns that could be covered.
- On the other hand, most of the "real" problems in infrastructure software come from adversarial action. Most software systems run more or less fine by themselves, from a professional liability standpoint. Adversarial action is not usually covered by "professional liability". For example, nobody blames the architects of the Azovstal plant that the steel furnaces couldn't stand up to sustained artillery bombardment.
- Despite all the talk about how critical software systems are these days, 99% of systems out there is the equivalent of a garden shed and nobody would care if it falls over. Certainly the shed in my own garden would not survive a proper hurricane, but that is OK because a. we don't really get hurricanes here and b. the cost to completely rebuild it would be much lower than bringing it up to hurricane standards. Even Maersk, which is surely not a small target, managed to survive a full blown ransomware hit just fine. (By which I mean, they took a fairly large hit financially but nobody died and no ships sank. By and large all vessels even reached their destination on time) Their IT had to work a lot of overtime for sure, but "the system" is not as vulnerable as people like to claim.
So what to do? I would not mind some form of legally mandated checklist to follow that would be mandatory for any company offering services on the internet, but at the same time I don't think it would be very effective in countering the worst threats and I also don't think it would be proportionate for most companies.
If your shed exploded into millions of shards of glass when struck by high wind that would be a different story. Or if it spread toxic chemicals all over your neighborhood. Or if it caught fire easily and the fire could spread to other buildings. Who would have thought sheds would make such wonderful metaphors?
My point in the GP was that most software (even in the biggest of enterprises) is more like a shed than a skyscraper: not very well Engineered and also not very critical. Even Maersk can apparently survive just fine without their logistics planning software for over two weeks. What would be the appropriate level of regulation for software that is apparently not all that critical? I think the appropriate level of regulation for most software would be extremely low, because not much is at stake.
Adam Smith, The Wealth of Nations
It doesn't mean that everyone who writes code must be licensed. But to determine if software is fit for purpose you must be. Liability is important and software doesn't have to threaten life and limb to benefit from it. Many engineering professions also protect property and business interests (along with life and limb).
What I hope such a system would provide is a means to prevent companies from cutting corners for the sake of profits and give engineers the right to say what is fit for purpose. Too many breaches that have cost economies too much money happen because IT is incentivized to release now and fix it later. Then hundreds of thousands of peoples' financial details are leaked or their pensions disappear. And the current system of liabilities don't protect the end users or dissuade the software industry from continuing on this destructive course.
We also don't account for externalities well. Consider how many years PoW crypto mining has been going on, growing, and forcing new coal plants to open to keep up with demand. People in rich countries don't care because it's not happening in their backyard and it is promising to make some of them rich. That happened because we have no social safeguards against bad technology harming the environment/society/etc. You can write a software service that exists to use up as much energy as possible and you will never face any consequences for the damage caused.
We barely slap people on the wrist for organized crime let alone corporate crime, negligence, etc.
We're not talking about your high school web project here. We don't have to prevent people from learning and building things on their own. I just think we need to prevent companies from rolling the dice with our future and let the folks who know what they're doing run the show.
I don't think we have the legal frameworks set up yet. Even where I'm from the professional engineering guilds are trying to move in on software but the enforcement is too weak to be useful.
I mean that, at least in Canada, there aren't strong legal frameworks that require P.Eng to sign off on projects, to manage development teams, the protect their jobs, liability, etc.
So far from others who've received the designation it's mostly "just paper" for now.
Of course we don't really know how well that test maps to real world competency!
I find that, at companies that tend to beat market expectations it's already like that. You can always tell whether they consider engineering a cost center or a core part of the business. It's no accident that the CEOs of the majority of fortunes 5 are engineers...
A lot of regulators are valuable but we've also got a lot running around with red tape and power trips that they didn't earn. We're extracting thousands of dollars from low-income minorities for hairstylist licenses that benefit no one. We've got engineering boards punishing people for publicly (and correctly) disputing the math of red light timing. There's too much abuse.
Regulation isn't just one way. Regulators need to be held accountable too.
Imagine for a second that the ransomware attack comes via an attack vector because, say, there's a security bug in Spring, giant Java library/ecosystem, that almost everyone pays zero for. Then imagine that this is in a world where the engineer is liable. How does this play out?
First, you could claim that the bug is in OSS Spring, and that they can't waive liability. In that circumstance, I'd be surprised if OSS continued existing: You get very little for your contribution in comparison to the liability risk. It's the same for corporate sponsored OSS: Imagine telling your company's counsel that you want to open source a library that is unrelated to the core of your business. Never. So this either has cataclysmic consequences to OSS, or we get to say that anyone making OSS's legal disclaimers are legally binding.
So what happens instead? Anyone building applications for a company is responsible for all the bugs in the libraries they chose. OSS will still be mostly poisoned by this. Imagine the fun of taking liability, as some kind of signing engineer, for a half a million lines. And those lines are almost sure to have some vulnerabilities: It's just that we don't know of them yet, and you need patching forever, just like you do today. And along with the patch, we'll have great discussions about who brought in the patch that introduced the vulnerability.
Note that this is especially fun in a world where security is covered by this. It's one thing to assume that ones code to control a car will not accelerate without bounds, risking deaths to the passenger. Then your design is narrow, and can have a semblance of good testing. Testing that your code cannot be used as part of a security vulnerability is testing a far wider field of possible inputs.
Either way we slice this, all I see is the world building a whole lot less software, because the dangers of writing it make all kinds of products dangerous. We either move to a world where a lot of code is shared and owned by a few companies that take all the liability, and hit major trouble whenever they have a vulnerability, because suddenly they are to blame for possibly millions of breaches, or a world where we share very little code, we evaluate it more thoroughly, and we hope nobody pays attention. I bet my libraries to handle certificates would be worse than the ones experts built today, but I could hope nobody examines them.
But yes, as others say, the world could do this right now: We can hire a firm to build something and take the liability for us. It's just that, in general, we don't, because they don't give us anything more secure, or better: mostly more expensive. Instead we might just buy insurance, and hope we don't have too much of a counter-party risk.
If we cut security vulnerabilities out of the equation, maybe there is a good defense that the world the author describes might be different, but not worse than the one we live in today. But with security? Tough.
> As with software product liability, the astute reader is apt to exclaim, "This will be the end of IT as we know it!" Again, my considered response is, "Yes, please, that is precisely my point!"
Since I started in the early 80's every generation thinks they can standardize things, license programming, make things from perfect reusable parts that work perfectly, and generally turn programming into recipes. Every generation fails.
In reality software is a mess because none of those things are possible because complexity is inherent in what we do, and what is expected of us, and there has never been any way to satisfy everything we are asked to do with some magical silver bullshit, err, bullet.
Even if you wanted software "Professional Engineers" to be a thing, how would you even do that, with 100's of programming languages, operating systems, software environments and industries all with different needs, and in an industry that changes every single day. Bridges have been built for thousands of years, software has changed radically and continuously since I started in 1981. As soon as you defined some standard to test against, it would be obsolete.
While I don't know the specifics for bridges, I have seen the specifics for the joist industry (those metal rails with Ws inside them that you see when you look up at the ceiling in a Walmart).
There is some design work that an engineer needs to do for any given job. However, they pick the type of joist, material, and wield (etc) based on a book that publishes weight tolerances. And those numbers come from someone taking a joist out someplace and dumping weights on it until it collapses.
We just can't do the same thing with software. It's not even clear what kind of weight we would be dumping on software. Human comprehensibility? How do you measure that?
A bridge is deployed in a single instance, in a single environment with a specific type and quantity of traffic. Everything about what a bridge does is known and quantified. As a rather direct example, look at the software that runs traffic lights; doesn't really ever fail, every possible state is covered, and as a result we trust with our life that when our light is green, the cross-traffic is red.
There's plenty of software that is as reliable as bridges. On the other hand there's a lot of professional engineering that I would trust far less than a web app. Things like high-end cars, sports equipment, rockets, etc. are all signed off by professional engineers but have an incredibly high failure rate.
(I talk a bit about the similarities between civil and software engineering here: https://www.hillelwayne.com/post/we-are-not-special/)
There are novel bridges that get built. They tend to be much more expensive, and come with more problems.
Computer security is definitely a problem. But this argument by analogy simply doesn't work. Moreover, non-computer security is a problem too. (School shootings, anyone?) Anyway, talking about toilets and whether they work isn't helpful at all in this case.
Ergo, there's no incentive to fix it, and every incentive to keep it broken.
https://en.m.wikipedia.org/wiki/Screw_thread#History_of_stan...
Get the government to require a standard for all their software and anyone who wants a government contract will have to conform.
- As noted at Wikipedia, wartime mechanisation and the requirements for standard parts to be provided for the new high technology of motorised transport, armour, and aircraft, drove further standardisation.
- The noted socialist and collectivist,[1] Herbert Hoover, provided the final push toward standardisation of weights, measures, and engineering components, as Secretary of Commerce.
It turns out that military needs and government legal authority and purchasing power can do much to promote standardisation which the free market cannot.
A subsequent case emerged during the Vietnam War during which the US Navy, a/k/a the transport and logistics arm of the US military forces, faced a critical problem in delivering supplies and materiel to very underdeveloped South Vietnamese ports. Though there'd been multiple attempts to standardise shipping around a single container size, this proved to be the ultimate nudge which established the TFU, or twenty-foot unit standard. (Now largely seen in its doubled form, the 40-foot shipping container.)
________________________________
Notes:
1. Sarcasm, gentle reader.
Could it just be that compatibility is not monetarily incentivized? And incompatibility is not punished by some regulation enforcement bureau?
No, it's something that one would be fired as a decisionmaker for not understanding. It's basic.
While mechanical connectors have existed for millennia, standardized connectors were a set of fairly recent innovations from the industrial revolution [1], with notable standardizations like unified thread as recent as post-WWII. So they're both new and took time for all of the standardizations to settle to what we have now. And the state of mechanical connectors is not static. There is constant innovation. Consider medical, military, and other applications with special demands.
Seen in that light, software is very rapidly standardizing. Like everyone else here, I feel your pain, though.
[1] https://www.nord-lock.com/insights/knowledge/2017/the-histor...
Software is language. It is as slippery as all other human languages when you try to pin it down to absolutes.
It is much like medicine in the time of the "four humours". The state of medicine then was a real problem, but if you were to have instituted licensing and professionalisation requirements at that point, it would largely freeze into place a bad situation. The other industries with licensing, have established a good, safe way of doing things. Software has no good, safe way of doing things to establish as code, and teach to new practitioners. I do not exaggerate, either.
On the other hand, what he suggests as a solution, would require that innovation be slowed by at least one, probably two orders of magnitude. Any nation which did _not_ do this, would quickly sprint ahead of those who did, and they would quickly be able to overwhelm the capabilities of the nations who had professional licensing requirements.
Before contributing you would need to upload your engineering certification credentials.
Good luck getting certified if you are under 18 or do not have a college degree.
Also, because of liability issues, employers may prevent you from contributing to open source.
Now I think you're talking about something that large companies could get behind: a massive barrier to market entry and competition that simultaneously neutralizes the threat of open source software while allowing them to sell it.
This is a great way to establish a new system to elicit corruption like you get with building permits etc. After all, you don't want your design to be stuck for 9 months waiting for approval, do you?
I wonder what level of liability would be reasonable when considering the increasing sophistication of these types of hacks. Going back to the bridge analogy, we would hold the licensed engineer responsible if the bridge they built collapsed because of a thunderstorm, but not if the bridge collapsed because a terrorist or rival nation state bombed it. Which of those situations is more analogous to getting hit with ransomeware or some other type of hack?
Say a piece of software from a small company is compromised, should the liability be different if the attacker is some script kiddie versus if it's some hacking group that likely has ties to a foreign intelligence service? Is it reasonable to expect every software company to be able to fend off even the most well-financed attack?
https://www.hillelwayne.com/post/are-we-really-engineers/
But the people responsible for the Colonial Pipeline are not Software Engineers. SWEs are just workers. Why don't we start to hold the people accountable who extract wealth and give orders? Power and responsibility should go hand in hand.
SWEs _want_ to engineer, make things more performant and secure. They _want_ to say No to unnecessary features. This takes time, trust, money. What about the owners? The board? The executives? They make the decisions, want fast growth, more features, less expenses, software to be a commodity and engineers be interchangeable. Managers and sales people, who buy and sell software packages with fancy names on them to get a promotion, don't do the soul sucking work of integrating with a buzzword driven hodgepodge. Shouldn't they be held accountable first?
With that out of the way...
The example in the article is the Colonial Pipeline ransomware attack. A cyber _attack_. Are bridges, toilets and buildings generally built to withstand arbitrary hostile attacks?
But Lack of understanding of how decisions in the IT industry are made, ridiculous examples and bad analogies aside: I still think there is a good point hidden in there somewhere. Namely that good engineering takes time, investment, auditing, standard processes and a strong technological foundation. But we are not there yet. Nobody is laying the foundation to get us there. It's just iterations upon iterations and layers upon layers, features upon features.
Before we can even start to think about licensing SWEs, we need to start thinking _very_ long term. Much of the SWE effort is funneled into short term monetary gains, while fundamental technologies like OS's common file formats, browsers, firmware and all that stuff is rarely reconsidered and just patched over continuously. The foundations are _inherently_ insecure and the mindset is wrong. Familiarity and productivity often take precedence over simplicity and robustness. Everyone thinks they are entitled to telemetry and other user data and most software is closed source. How do you reason about black boxes? How do you trust them?
Also who will do the licensing? The people who tend to push for these things while shitting on other software practitioners don't inspire much confidence IMO.
I have so many questions...
Precisely. It's the company with it's "disclaimer of all warranties express or implied" that would/should be liable.
I'm not sure how this works for free/open source software however. Presumably liability passes to whoever is charging for the system or service.
Has Kamp ever read any SciFi published after the '70s? That's a pretty common trope in cyberpunk and subsequent works. Heck, it's a staple of Mr. Robot, hardly a niche production.
Even security devices like locks and fences are trivially defeated with the right know how and tools.
If architecture, construction, and civil engineering firms could implement automatically binding license agreements that absolved them of all liability and responsibility, we'd probably see similar results.