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.
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)
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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 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 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.
Readit News
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.
The service part seems more like greed than something I want (in many cases, certainty not all)
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.
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.
Most of us are NOT engineers. Even less build software as engineers.
Deleted Comment
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.
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.
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.
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.
At the same time, there’s also no other industry that operates at a fraction of the speed of this one.
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.
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.
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.
Deleted Comment
They are always really enthusiastic and positive though.
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.
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/)
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?
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.
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.
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 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.
Deleted Comment
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.
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...
I thought there wasn't any longer any exam for people to take in software engineering to become professionally licensed in the US?
Deleted Comment
Adam Smith, The Wealth of Nations