[HN Gopher] The Software Industry Is Still the Problem
___________________________________________________________________
The Software Industry Is Still the Problem
Author : pabs3
Score : 107 points
Date : 2022-05-30 13:46 UTC (9 hours ago)
(HTM) web link (cacm.acm.org)
(TXT) w3m dump (cacm.acm.org)
| civilized wrote:
| 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.
| hibikir wrote:
| 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.
| zokier wrote:
| 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!"
| [deleted]
| DeathArrow wrote:
| 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.
| toyg wrote:
| _> 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.
| alaricus wrote:
| Why is it mechanical engineers have standard sizes for all nuts
| and bolts but software engineers can't pull off the same feat?
| I_Hate_Devs wrote:
| 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".
| hwayne wrote:
| McMaster-Carr offers 1,533 different kinds of thumb screws with
| 27 different thread sizes.
| https://www.mcmaster.com/screws/thumb-screws/
| seclorum_wien wrote:
| No software ever works without defining nuts and/or bolts.
|
| Software is language. It is as slippery as all other human
| languages when you try to pin it down to absolutes.
| drewcoo wrote:
| 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.
|
| [1] https://www.nord-lock.com/insights/knowledge/2017/the-
| histor...
| BlargMcLarg wrote:
| 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.
| bokchoi wrote:
| I'd say some things have been standardized quite well - 8 bit
| bytes, Unicode, http. It's the application layer that isn't
| standardized.
| throwaway787544 wrote:
| 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.
|
| 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.
| dredmorbius wrote:
| Further parts of that story:
|
| - 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.
| eptcyka wrote:
| Incompatibility is incentivized monetarily. Everyone wants to
| build something with a captive audience.
| I_Hate_Devs wrote:
| 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.
| drewcoo wrote:
| That's a pessimistic view at best.
|
| Could it just be that compatibility is not monetarily
| incentivized? And incompatibility is not punished by some
| regulation enforcement bureau?
| pessimizer wrote:
| > That's a pessimistic view at best.
|
| No, it's something that one would be fired as a
| decisionmaker for not understanding. It's basic.
| alaricus wrote:
| EU is now forcing tech companies to be compatible. It will
| take time, but EU is the only major force pushing for
| interoperability.
| alaricus wrote:
| This is the correct answer.
| throwaway787544 wrote:
| 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.
| coldcode wrote:
| 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.
| hotpotamus wrote:
| 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.
| marcosdumay wrote:
| 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.
| dghlsakjg wrote:
| 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.
| hwayne wrote:
| I have met bridge engineers who had to move bridges after
| they were built.
|
| (I talk a bit about the similarities between civil and
| software engineering here:
| https://www.hillelwayne.com/post/we-are-not-special/)
| Verdex wrote:
| 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?
| mikewarot wrote:
| >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]
|
| 1 - https://en.wikipedia.org/wiki/Unidirectional_network
|
| 2 -
| https://en.wikipedia.org/wiki/Office_of_Personnel_Management...
| webmaven wrote:
| _> 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.
| mikewarot wrote:
| I hope they've updated that system to use a data diode,
| instead of deciding it was _too careful_.
| randomdata wrote:
| _> 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.
| mikewarot wrote:
| >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.
| randomdata wrote:
| _> 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.
| bee_rider wrote:
| 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.
| lr4444lr wrote:
| 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.
| cm277 wrote:
| 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...
| analog31 wrote:
| 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.
| Semaphor wrote:
| 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)
| thot_experiment wrote:
| 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.
| lumost wrote:
| 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.
| DragonStrength wrote:
| 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.
| randomdata wrote:
| 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.
| arinlen wrote:
| > _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.
| dghlsakjg wrote:
| 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.
| dinosaurdynasty wrote:
| > We don't harden every building for military attack.
|
| We might, if military attacks were as commonplace,
| untraceable, and unpunished as online attacks.
| cafard wrote:
| Were the designers of the Moehne Dam hauled into court
| after the RAF destroyed it?
| dchftcs wrote:
| 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.
| ThrowawayR2 wrote:
| > " _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.
| trashtester wrote:
| > Professional engineers working on buildings aren't liable
| for someone who decides to take a bulldozer to it to find
| its weakness,
|
| They are liable for things like earthquakes and explosions,
| though, up to some limit:
|
| https://www.fema.gov/emergency-managers/risk-
| management/eart...
| dehrmann wrote:
| The other key difference is we can experimentally break the
| bridge during testing at almost no cost.
| [deleted]
| skeeter2020 wrote:
| 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.
| [deleted]
| vishnugupta wrote:
| 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.
| Certhas wrote:
| 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.
| Digit-Al wrote:
| > 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.
| brightball wrote:
| You are 100% correct and this needs to be repeated often. There
| are very few things that can act as an analogy for software
| development.
|
| At the same time, there's also no other industry that operates
| at a fraction of the speed of this one.
| Supermancho wrote:
| > 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.
| fatbird wrote:
| I agree in general, but this:
|
| _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?
| thot_experiment wrote:
| 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.
| lr4444lr wrote:
| Fair enough: s/public/consumer
| atmartins wrote:
| 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.
| patrick451 wrote:
| 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.
| layer8 wrote:
| > the public wants constant innovation.
|
| 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.
| bodge5000 wrote:
| 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.
| DragonStrength wrote:
| 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.
| flappyeagle wrote:
| Author misses the point entirely. Almost nothing in the real
| world is engineered to prospect against motivated malicious
| actors.
|
| Even security devices like locks and fences are trivially
| defeated with the right know how and tools.
| WJW wrote:
| I'm a bit on two feet about this article:
|
| - 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.
| drewcoo wrote:
| 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?
| WJW wrote:
| 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.
| lapcat wrote:
| 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.
| dgb23 wrote:
| > 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.
|
| I have so many questions...
| sreeramb93 wrote:
| That's why SLAs exist?
| petermcneeley wrote:
| 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?
| edgedetector wrote:
| What industry do you wish to deregulate? Also, software is not
| unrestricted "progress." It is unrestricted "change," which is
| not always a good thing.
| shaftoe444 wrote:
| _" 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."_
|
| Adam Smith, The Wealth of Nations
| dboreham wrote:
| 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.
| pylua wrote:
| Is there a way to make this work in an agile framework ? It is
| more than just the Engineers this would effect.
| agentultra wrote:
| 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.
| chrisseaton wrote:
| 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.
| bee_rider wrote:
| 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!
| dimgl wrote:
| I think it does. I think the barrier for entry is way too low
| now.
| helpfulmandrill wrote:
| How does one do that? I realise this may vary by
| jurisdiction...
| chrisseaton wrote:
| I'm a 'Chartered Engineer' - you just apply
| https://www.bcs.org/membership-and-registrations/get-
| registe....
| agentultra wrote:
| I'm working on getting myself in there as well.
|
| 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.
| chrisseaton wrote:
| In the UK the legal framework is 'chartership', and
| 'chartered' is the legally protected word.
| spiffytech wrote:
| I highly recommend this interview series with engineers from
| other fields who moved into software:
|
| https://www.hillelwayne.com/post/are-we-really-engineers/
| rossdavidh wrote:
| 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.
| petermcneeley wrote:
| Do you ever wonder how much medicine has been slowed down?
| rossdavidh wrote:
| 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.
| randomdata wrote:
| 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.
| chrisseaton wrote:
| > The software industry offers the exact professionally
| licensed engineers who are subject to the liabilities spoken
| of.
|
| I thought there wasn't any longer any exam for people to take
| in software engineering to become professionally licensed in
| the US?
| randomdata wrote:
| Could be. It is a thing where I am from. The software
| industry doesn't even begin to end at US borders, that is for
| certain.
| pca006132 wrote:
| idk, maybe they should try to get politicians aware of the
| situation and setup regulations for this?
| [deleted]
| RcouF1uZ4gsC wrote:
| If we regulated software like engineering, it would destroy open
| source.
|
| 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.
| edgedetector wrote:
| 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.
| spaced-out wrote:
| >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?
| [deleted]
___________________________________________________________________
(page generated 2022-05-30 23:02 UTC)