Hacker News Reader

Comment by lr4444lr | Hacker News Reader

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.

View on HN

Hmmm, I think TFA misses the fact that software engineering, isn't really engineering any more. We don't develop code that gets deployed and stays in place (well, maybe in embedded systems, but even those are getting IoT'ed).

Modern software is a service: it gets updated all the time, it's "hired to do a job" rather than perform a specific function. The latter is finite, controllable and could potentially be certified as an engineering product. The former relies on professional codes (and yes liability as well) to make sure that the service is acceptable.

All that is to say that the proper metaphor isn't licensing as for civil engineering or telco networks but akin to licensing for professional services, like medicine, accounting or law.

Which means different tiers of service, different expectations and yes much different compensation/service fees. But to get there we have to stop talking about 'engineering' as the correct framework. We're closer to lawyers or nurses...

If you think of a software system as a manufacturing plant, you can make some pretty straight analogs to other engineering functions. I know plenty of engineers who work at auto plants, power plants, or the like whose jobs are much more traditionally engineering and look a lot like what a modern software job on a distributed system look like. The core business is modeled and run through the software. Things break and will need modification over time, so the engineers are always present. It's not that software is outgrowing engineering. It's that software is growing to look more like other professional engineering disciplines.

The businesses we support are predominantly the professional services you list, so maybe a mental model of a professional services factory is where we're headed? You're certainly not wrong that software engineers need to be comfortable in those environments, but I suspect there's a bit of motivated reasoning among those who see our career becoming more like doctors, lawyers, and accountants, though I would love that to be the case. If anything, those professional jobs are looking more like engineering jobs over time as their own moats have been eroded. Aren't the software engineers coming along to make those professional careers look less special? I'm watching all the local dentist and optometrist offices get purchased up by chains instead of a new generation of small business owners. I'm not aware of another profession which has risen to those ranks, so I suspect their current place is merely a historical relic which is passing.

Not to mention that security seems to be his primary concern. Professional engineers working on buildings aren't liable for someone who decides to take a bulldozer to it to find its weakness, so it would be equally unreasonable for engineers to be liable for someone taking a 'virtual bulldozer' to software to find its weaknesses. What humans can dream up is an unknown and unpredictable quantity, which is incompatible with engineering.

When it comes to software operating within known constraints, we're usually pretty good at delivering. The software in your car, for example, may be full of security holes if a human decides to attack it, but as far as working within the known environment, it is likely to work just fine and as expected. That is all we would expect of a professional engineer.

If you want to stop people from driving bulldozers into your buildings, you're going to have to look beyond the engineers. That is not their area of expertise.

> Professional engineers working on buildings aren't liable for someone who decides to take a bulldozer to it to find its weakness, (...)

Actually, they are.

Engineers are tasked with designing safe structures taking into account a bunch of failure modes, not only those that involve safety but also usability.

These failure modes are even covered in standards, and engineers who fail to design projects which are safe under these scenarios are held liable both civil and criminally.

There's a limit to these things. Residential houses are not designed to withstand machine gun fires. Or a novel chemical, or even just an uncommon but nasty one.

> "Residential houses are not designed to withstand machine gun fires."

If machine gun fire were a daily occurrence for residential houses, they would be. Every other common occurrence that occurs to residential houses, whether it's fire hazards, snow load on the roof, earthquake protection, etc. is part of the design consideration for residential houses.

The fact that software _predictably_ gets attacked when placed online is exactly what means that developers can't shrug their shoulders and pretend it's an unforeseen event.

Except machine gun fire is consistent. Say you were to plan against guerilla warfare with various arms and various tactics that evolve each year because there's an arms marketplace. Could you?

How often do the people who pay for the software plan for that in their budgeting? Supposed I were to say this software has been pentested before release and it'll cost this much extra. How many people are paying for that? How many people will pay for it to be pentested each year for new vulnerabilities?

This is more like missing doors/door locks than machine gun fire.

They're not missing doors and locks; the auth layer exists, but it's not without weakness.

Most residential doors I've seen can't even stop someone with a credit card or metal shim, unless they have and actually use the deadbolt. The vast majority can be picked with ease if you have experience (and hackers typically do). You can also just check windows, since most people don't lock them.

If you don't have to leave the door intact, there's a billion ways to get in. You can ram through the door, since they're not terribly thick. You can drill out the locks. You can saw through the hinges and/or the bolts. If you really don't care, any number of guns can remove the locks or hinges.

An angle grinder will neatly handle any safe you're likely to find inside.

When you're deploying something to the warzone, there are many unknown unknowns that affect the outcome. Things get predictably attacked and the defense can get unpredictably destroyed.

Firearms and tactics evolve over time and very few things can really be blamed on the engineer. The rules for PE are also based on evidence of due diligence on known problems rather than absolute liability, because nobody knows everything that could happen, and can't cover all possible failures. You should read up on how tanks are destroyed or stopped in inventive ways in guerilla warfare, such as in the ongoing Ukraine conflict (it's not just failure of maintenance) or in Vietnam war.

I also don't understand why you could selectively skip the part about novel chemicals.

I suspect the point is more that PEs and architects are supposed to deal with a known set of threat models, most of which ARE NOT nation states deploying dedicated teams to getting inside the building. We don't harden every building for military attack.

Software, on the other had is expected to stand up to being exposed to nation state level threats that we know about, as well those in the future that we don't know about.

We can't get mad that Sony was hacked by North Korea in the same way that we wouldn't be mad at the engineers if the studio building burnt down after being bombed by the North Koreans.

> We don't harden every building for military attack.

We might, if military attacks were as commonplace, untraceable, and unpunished as online attacks.

We might if people paid for it.

Were the designers of the Moehne Dam hauled into court after the RAF destroyed it?

The buildings in the path of Killdozer[1] didn't stand up. The machine penetrated them with ease. Are the engineers who designed them in jail now, or what? Or was it understood that designing a building to not give way to the fate of a rogue bulldozer was not a necessary feature of the original design because at some point you have to accept that a determined enough human will find a way in no matter what? Even if you do design it to withstand a bulldozer, the determined human will just bring in something more powerful. The determined human is clever and unpredictable, which doesn't realistically fit the engineering model of working within known constraints.

I would offer that there is good reason why building security (e.g. police) is its own profession, not a traditional engineering discipline.

[1] https://www.cpr.org/show-segment/this-man-barely-escaped-kil...

> 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...

In a way, most of my favorite pieces of software are not that. MediaMonkey 4, Ynab classic both stopped getting updates, DirectoryOpus has only been getting fixes and scripting additions for years. Yet they are my favorites and better (ynab, MM) than their successors.

The service part seems more like greed than something I want (in many cases, certainty not all)

Couldn't agree more. Software COULD just solve a problem and then get out of your way, but because we're stuck in a world where MRR is king people are forced into making SaaS trash where the incentives aren't aligned to deliver what technology is capable of. Photoshop/Illustrator was less buggy years ago, and consequently I now just use ancient pirated versions. I feel zero percent bad about this, I'd buy em if I could. Same with Windows, LTSC frozen out of updates is an infinitely better experience than whatever monstrosity Microsoft is peddling these days. Total Commander has been solving the same problems the exact same way perfectly well for 20+ years.

I love innovation as much as the next guy, there are constantly legitimately great advancements in software. That, however is not the same thing as a constant drive for change for changes sake. I want to pay a fair price for tools I can rely on today, not nebulous promises of future improvements that result in tools and processes being broken from time to time. It's not worth it. It's not a good trade-off. The idea that I can have something working perfectly fine and have it suddenly break the next day through no fault of my own is fucking abhorrent. I'm not here for it.

I've written services at startups that I know were in place 10+ years later. I'd be surprised if the majority of my code was still powering them, but never the less, when you solve a hard problem well - software has quite a bit of staying power. You see similar trends in the PostgreSQL code base where critical code pieces/structures date back to 1991 in some cases.

I'd doubt that a professional certification is needed for practitioners of software, but I could see merit in a certification body for software products. There are software products used in critical use cases, where the standard of practice for security, operations, or testing is insufficient for the desired use. As a client of such products, I might choose the "certified" version over the un-certified in a space where I don't believe feature velocity matters.

The problem with any of this would be making a compliance regime that didn't boil down to a boring ineffective process.

There are also physical products that are un-engineered, such as pretty much any one-off made by a craftsman or DIY'er, but engineering is still engineering. The unique thing about software is that an unlimited number of craftsmen and DIY'ers can be brought together to make things of limitless complexity.

I understand where you are coming from, but this is not completely true. We often build physical infrastructure & buildings that need to evolve and change over time. This sometimes leads to over-building and often over-engineering but the biggest difference is we don't usually design & build software to true engineering standards. We move quick and break stuff, fix it after release, waterfall is outdated and maligned, nobody is held responsible for catastrophic failure.

Most of us are NOT engineers. Even less build software as engineers.

> 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.

That's what people claim they want, but it's not how they vote with their wallets.

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.

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.

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.

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?

Fair enough: s/public/consumer

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.

The other key difference is we can experimentally break the bridge during testing at almost no cost.

> the public wants

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.

Reply on news.ycombinator.com