I think it’s not that software engineers aren’t engineers; but more that they’re most equivalent to combat engineers — engineers operating under time-pressure and shipping-pressure, where the systems they build need to “work” (in the sense of a bridge getting people across a ravine) but may only need to work once; and where it may be perfectly fine/expected/required to need to “baby” the resulting engineered system along (i.e. letting a batch of people over the bridge, then closing it to traffic, examining the piles for faults, and shoring up the ones that are slipping; then reopening the bridge, in a cycle.)
It’s not that this type of engineering is “not engineering”; it’s that it’s engineering where the engineer themselves (and their ability to actively re-stabilize the system) is considered a load-bearing element in the design, such that the system will very likely fall apart once that element is removed.
Combat engineering is still engineering, in the sense that there are still tolerances to be achieved, and it’s still a disaster if the bridge falls over while it’s in active use for the mission it was built for. It’s just not considered a problem if it falls over later, once that mission is accomplished.
I think software developers have a range in terms of responsibility from plumbers/electricians to civil engineers. We could save the designation “software engineer” for someone who has to go through the requisite ethics and case study courses like all other engineers. Otherwise maybe programmer/developer. (I’m gatekeeping I guess)
I would think it's less about ethics and more about understanding consequences; being able to reason about what happens based on the choices made while implementing something.
Given the same conditions (i.e. people don't die) the same outcome would present itself. We have a history of bridges falling down, so much so that Wikipedia has a list on that: https://en.wikipedia.org/wiki/List_of_bridge_failures
A particular one that caught my eye:
Cimarron River Rail Crossing Dover, Oklahoma Territory United States 18 September 1906 Wooden railroad trestle Washed out under pressure from debris during high water 4-100+ killed Entire span lost; rebuilt Bridge was to be temporary, but replacement was delayed for financial reasons.[8][9][10] Number of deaths is uncertain; estimates range from 4 to over 100.[11]
Emphasis mine. How is that different from software engineering?
The point isn't that bridges never fall down. The point is that engineers who build bridges know that it's their responsibility to do everything in their power to make sure it doesn't, even if no-one else around them seems to care about that, or specifically asked for it. That they should walk away from a project rather than sign off on one where they will not have the resources or support to do a competent job.
That said, all bridges have design specifications and limits. If someone drives a convoy of trucks carrying gold bullion over a bridge and exceeds its design max weight by a factor of 10, and it doesn't hold up, that's not the engineer's fault. If a bridge is designed for a geologically active area and is designed to withstand a quake 10x more powerful than the strongest that's ever been recorded in the area, or is predicted by seismologists, and the area gets hit by a 100x quake, that's not the engineer's fault.
And if a bridge designed to last say, 5 years, is neither re-certified for use, or just closed, when its intended lifespan is up then that's not the engineer's fault either.
But the engineer is responsible for finding out what the likely max load of a bridge will be, or how powerful the strongest quake will be, or how long its intended lifespan is - and for adding in safety margins on top of that. They can't just assume that any new bridge will only be needed for 5 years, just because that no-one told them that it will be needed for longer, and then claim "well, it was only temporary" afterwards.
> The point isn't that bridges never fall down. The point is that engineers who build bridges know that it's their responsibility to do everything in their power to make sure it doesn't, even if no-one else around them seems to care about that, or specifically asked for it. That they should walk away from a project rather than sign off on one where they will not have the resources or support to do a competent job.
The law takes care of that though. The law and inspection. If it was up to the business, any engineers building bridges who would refuse to project it faster because of that would be fired.
Yes, but not because software engineers are worse human beings than civil engineers, which is all too often the undertone of these discussions.
Rather, because software engineering hasn't killed enough people to advance; or when it has, it wasn't obviously the culprit.
In which fields of software engineering do we find actual solid procedures and standards? Avionics. Medical hardware. Fields where the link between bug and death is as short as possible, and so the stakeholders have demanded solid engineering.
What are the consequences of GP's acquaintance writing poor code? Some trading firm becomes slightly less efficient at trading. Impossible to evaluate the net human loss from it (if it's a loss at all).
The civil engineering equivalent would be something like façade design or layout. If your building is ugly or confusing, it will annoy or waste the time of the people who live and work in it, but as long as it doesn't fall on their heads nobody is going to withdraw your certification.
> not because software engineers are worse human beings than civil engineers, which is all too often the undertone of these discussions
I think the undertone is usually that the software developer at fault had no idea what they were doing, and had no place working on critical systems, rather than that they had ill intent.
There seems to be plenty of software issues found:
The MCAS software was modified to read from both angle of attack sensors and to be less aggressive in pushing the nose of the plane down. The software that controlled the indicator light that illuminated when the two angle of attack sensors disagreed was also fixed.
While reviewing the software systems, a number of other software issues were found.
The wiring bundle issue was also found during these reviews.
I phrased that poorly, I should have said The 737 Max issues that caused the crashes were not with the software implementation. They were at the level of requirements and high-level design, and were not specific to the discipline of software engineering. We're not talking about a missing break statement here.
> The MCAS software was modified to read from both angle of attack sensors and to be less aggressive in pushing the nose of the plane down.
That strikes me as a design issue in the domain of aeronautical engineering, rather than in software engineering. Software engineers aren't the ones with the domain expertise to determine the right aggression parameters.
> The software that controlled the indicator light that illuminated when the two angle of attack sensors disagreed was also fixed.
I thought the issue was that the sensor-disagree warning light was not included as standard, it was sold as an optional extra. [0]
> While reviewing the software systems, a number of other software issues were found.
Interesting, I wasn't aware of that. If I understand correctly these issues aren't thought to have a direct bearing on the crashes.
Exactly. People seem to have skipped the V&V lectures. The code did exactly what it was asked to do. But the system/aero engineers made that decision. Even the lights issue was specified that way in the system diagram.
But the biggest defect was the decision that the pilots didn't have to be told about the risk (to avoid retraining and certification costs). If they had been told the pilots/airlines may well have protested about the lack of redundancy. All those higher ups in Boeing and the FAA should be in prison.
I don’t think that is too far off the mark. Given 8 more decades of progress we might even be able to produce reliable code. Webpages will be 100GB of JavaScript though
> Given 8 more decades of progress we might even be able to produce reliable code
As the risk of nitpicking, we already can produce reliable code, but as piaste's comment states, it's rare to make the necessary investment.
Avionics software and medical systems software is held to a very high standard, at great expense, but the average website or desktop application is not.
> Webpages will be 100GB of JavaScript though
I agree that the problem of bloat is likely to continue to worsen in the web, but that's just the web. Other sectors, like high-performance game engines, will continue to compete on efficiency.
I think reliability is, after a certain point, inverse proportional to the amount of code involved. So I'd disagree that we'll have even larger webpages then - the same way that in modern construction, heavy and thick stone & brick pillars have been replaced with comparatively light and strong steel-reinforced concrete. Maybe the equivalent would be just enough strongly typed code running on top of just enough, well tested & secure WASM?
"I need that bridge yesterday. If my army doesn't cross the river today, we are all dead. I don't care if the bridge collapse tomorrow, or if the rain wear it down, as long as I can use it today."
If it's your job to do what is requested from you, then you do it. It's not like having brittle unmaintainable code is morally wrong. It's not engineers responsibility to judge use case of the customer paying for the bridge.
>It's not engineers responsibility to judge use case of the customer paying for the bridge.
Actually yes, yes it is! I am a civil engineer and there's a standard of ethics and personal responsibility among engineers that is very, very high. When we graduate, most engineers participate in a ring ceremony. They get a funny, angled ring on their right pinky. It was originally made from the metal from a bridge that fell down and killed people. It was meant to be a daily reminder, worn on the drafting hand, that every single drawing you signed carried the weight of public trust of their lives. Even pedestrian bridges get built with vehicle load standards, because you can't just assume that it will only be used by pedestrians.
Civil engineering is a licensure, and no matter what liability structure you use, when you stamp a drawing, you carry PERSONAL liability for anything that might happen if that design fails. Even small violations of ethics or operating outside your scope of knowledge are dealt with very aggressively by the licensing board.
In school, if we misplaced a decimal or got a calculation wrong or failed to adhere to a very specific standard, it was automatic failure because if you do that in real life, people die.
It is difficult to compare software development with civil engineering as they operate on different levels.
Software development is better compared to building houses. No one expects single story house to support 4 extra levels or for internal walls to be resistant to hammer blows.
Imagine what civil engineering would produce if you were building a bridge from a to b and then 3/4 way through you were required to add two extra exits c and d that were miles apart from a and b and another 4 lanes and extra level for train traffic...all in the same time frame and for no extra cost.
Civil engineers would not be able to do it and no-one would even expect them to but this is regular occurrence for software developers and most of them actually manage to deliver.
Sure there are bugs but bridges need constant maintenance too, some quite substantial and that is expected.
For some reason, lots of non-software engineers expect software to be perfect when their own products are not, not even close.
This is a key common thread in all these discussions. At so many development shops, developers have no agency to push back against poor quality. They don't have a license on the line that they can stand behind and firmly say "NO we will not do it that way or I could be personally liable for its failure!" When they point out that they're shipping buggy crap, the response simply is: Ship the crap on time.
It's strange too, you hear in other threads about how high the demand is for software engineers, how high their salaries are, how much negotiating power they have with their companies, but when it comes to the actual product content, suddenly they have no power at all and it's just Yes boss, whatever you say, boss. How is this true?
> I am a civil engineer and there's a standard of ethics and personal responsibility among engineers that is very, very high.
And that is because no one can just go to a 6-month bootcamp and call themselves a Civil engineer. And even if they did, no one would hire them or the employer would go to jail.
If we want Software Engineering to be as rigorous as other Engineering disciplines, we need to erect similar barriers to become a Software Engineer.
Honestly, I think it would be sensible to have a software engineering licensure, though it shouldn't be required for all developers or development. I'd say something like an engineering stamp would be pretty reasonable for anything requiring encryption, financial data or transactions, health data, etc. And that's not to say that developers couldn't work on it, but just that a licensed software engineer should be in responsible charge of their work to ensure that it has been performed according to best practices and standards.
Is this the same in Europe? I doubt it and at least in Germany an engineer (even a software engineer) is someone who has studied a technical subject at university. It has nothing to do with liability here.
The exact protected term varies by country but there is an equivalent license in Europe. The EU has a "Eur Ing." title issued by FEANI which is roughly equivalent. As I understand it, Germany is a bit unique even for the EU. They still have some things which require a certification of sorts, but I don't know exactly how that works.
That is a really weird analogy. Using extreme scenarios to argue your point is never going to put you on a strong footing.
Anyway for most systems deployed the customer usually wants to maintain a business using it. If the system constantly falls over, cant be readily changed etc etc that is going to cost the customers business compared to its competitors.
Add that a lot of developers work for the same company as the customer and that is just as much the developers responsibility.
99.999% of bridges built would be expected to hold up 10 years later and require minimal maintenance. I'd wager all bridges even temporary army ones would be expected to not unforeseeably fail. See the Morandi Bridge tragedy.
Enginners where not requested to make the Voyagers last a hundred years, yet they're still up and running. Personally I think the correlation between quality of code and time to delivery are not linear. People can cram more work and quality in the same ammount of time if they want and have the right incentives to do so.
The state of software engineering these days resemble that of civil engineering of late 19th century: some masterpieces, some failures and lots of experiments.
Do we put the cockpit in front of the boiler or behind?
Do we make a walking steam engine? How about using gears instead of wheels?
Which gauge to pick for the rails?
We'll get there in software engineering at well. It will be very reliable and equally boring.
There may be reasons for not calling software developers engineers but this is not one of them. The software "bridge" in this case has the following properties:
1. It can be rebuilt in a matter of hours by a single person.
2. The customers that ordered the bridge are also the people on the bridge and are totally fine with the bridge crashing on them from time to time.
#2 was the most frustrating thing (to me) about writing software, and ultimately what got me to move out of coding over to other areas of the business. This universal acceptance of low quality and crashing. You always have the classic "Schedule, cost, quality, pick 2" tradeoff, and 99 out of 100 places you'll work will throw quality under the bus when push comes to shove.
I remember the exact turning point. We had a super buggy Windows application that had tons of crashes in it. Instead of root causing each crash and fixing them, I was asked to simply write a launcher app that sat in the background, waited for the application to crash, then re-launch it. That was the great solution. And it was totally acceptable to the customer. Arghhhhh! I remember thinking: I didn't spend four years in university to shit this kind of finished product out.
I guess the key reason why software developers are not engineers is that there is no barrier to entry. If a necessary requirement to build a bridge is to hire a certified Civil Engineer who has undergone the necessary ethics and reliability training, then you have no choice but to pay up for that certification cost. You can't outsource that work to Eastern EU or Asia or hire another one willing to "hack" the bridge to deliver it on your tight timeline.
On the other hand, if someone takes software reliability seriously, either they are going to burn themselves out to meet the crazy deadlines or are going to "not deliver on time", in which case they will be replaced by someone who can "get shit done" cheaper and faster.
> You get what you pay for, if you pay for developer you'll get a developer.
That's way too oversimplified. You can be as good and as thorough as you want, but if the root of the problem is that software is seen as a cost not as an integral part of the solution, you get bad results.
This often starts with unclear/vague requirements that change every other day as new information and understanding is gained.
But it doesn't stop there - unrealistic deadlines, lack of defined processes and quality control as well as disregard (and refusal to budget and schedule) for background tasks (documentation, refactoring, ...) are also contributing factors that can turn even the best and most diligent software developer into a messy code cowboy.
If gaming the system is rewarded more or actually doing a good job is even penalised, why do a good job?
I remember reading about bad software in a radiotherapy machine inducing many deaths. And also about software in Toyota cars failing and also inducing deaths because the code was a huge mess. In the end, there is no such thing as a clear separation between "engineer" and "developers".
Basically engineers care about the quality of the code because they know that is the design. As soon as caring about codebase quality leaves the building, so will the quality of the product.
A civil engineer will put their stamp on the design of a bridge certifying that it will not fail. If it does fail, they will be held responsible and may lose their license to practice.
Software engineers often hide behind a contract saying they aren't responsible for anything.
He is a qualified elec eng though, he's just found a non-engineering job that pays a lot more.
Software engineering is real and does require you to have a real understanding of risk (including through formal methods, model based design, systematic testing etc) in regard to the consequence. If you work in a more regulated industry (e.g. railways, aviation, automotive) these things are taken more seriously. This is why things like 'partial autonomy' driving needs more regulation -- no one is requiring Tesla to have a Chief Engineer sign off on anything meeting any standard.
There are _plenty_ of places in engineering where defects / quality / etc are lesser concerns, just like there are places in software development where they're a major concern. There's also a _lot_ more call for quality up high (ie, regulations) for the various engineering disciplines.
I would expect that there are plenty of engineers that look at faults in the systems they're working on and say, "management doesn't care, not my problem".
If software developers aren't engineers, why are we judging this person's engineering? I think this case is an argument that software developers are engineers, even when their employer fails to see it that way
On the opposite end you have programmed obsolescence for example that is definitely an engineering art.
It takes talent and effort to make things fail.
I would suggest that some in the field are developers while others are engineers. The former write some code that does what they tested it for, the latter designed code to account for every detail. The former thinks it does the job the latter knows. The former rushes through while the latter codes in ways that avoids redundant busy work to allow for the higher up front investment. The former slows over time as they slog through the "ball of mud" they call inevitable while the latter increasingly gains and shares insight on the deeper problems being solved and the opportunities afoot.
TL;DR: I think the extent to which we are engineers is a choice we individually make.
"No-one ever explicitly specified that the bridge shouldn't fall down and kill everyone who was on it at the time", said no engineer, ever.