[feintruled]

That's quite a tale, a parable almost about how software engineering differs from other jobs (I want to say 'real' jobs but tongue in cheek). I like this one too, it's even snappier.

A software engineer, a hardware engineer and a department manager were on their way to a meeting in Switzerland. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of control down the road, bouncing off the crash barriers, until it miraculously ground to a halt scraping along the mountainside.

The car's occupants, shaken but unhurt, now had a problem: they were stuck halfway down a mountain in a car with no brakes. What were they to do?

"I know," said the department manager, "Let's have a meeting, propose a Vision, formulate a Mission Statement, define some Goals and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way."

"No, no," said the hardware engineer, "That will take far too long, and besides, that method has never worked before. I've got my Swiss Army knife with me, and in no time at all I can strip down the car's braking system, isolate the fault, fix it and we can be on our way."

"Well," said the software engineer, "Before we do anything, I think we should push the car back up the road and see if it happens again."

[shadowgovt]

The big advantage to software engineering is we deal in abstractions. I liken it to building castles in the clouds; everything down to the foundation is reshapeable.

... the big disadvantage to software engineering is we deal in abstractions. Everything down to the foundation moves.

http://thecodelesscode.com/case/154

[xkcd-sucks]

Also, software is right now primarily a means of codifying human thought, which means it embodies the whole spectrum of human sanity and competence

[hathawsh]

That deep thought seems especially appropriate for XKCD, yet your username curiously suggests you would disagree.

[lostlogin]

> I liken it to building castles in the clouds

You’re very positive. When you see a developer dealing with a bug, it seems more like they are dealing with a turd palace floating in a sewer.

[qup]

Turds are shapeable, too. Hard to polish, I've heard.

But you control the poopy stack.

[cgriswald]

> [Turds are] hard to polish, I've heard.

Mythbusters did it:

> Adam and Jamie first visited the zoo to obtain a variety of feces to try to polish. Poop collected, they tried to pick the most polishable candidates, and then baked them to remove the moisture. Adam tried to shine his poop with a buffing wheel, while Jamie's tactic of applying a furniture polish caused a philosophical disagreement between the two. Adam eventually brought in an outside expert to teach them dorodango, a Japanese art form that allows a practitioner to apply a shine to dirt using nothing but water and physical effort. Applying this technique, Adam and Jamie were both able to polish balls of poop without using any foreign materials as judged by a gloss meter, exceeding a standard of 70 gloss units for high gloss.[0]

[0] - https://en.wikipedia.org/wiki/MythBusters_(2008_season)#Epis... (Section: You Can't Polish Poop)

[s1artibartfast]

Is the moral of the story that the hardware engineer is simply correct? - a mechanical engineer

[smt88]

It's mostly just a joke about how these roles do their jobs.

But I think it's also partly illuminating the fact that hardware engineers are true engineers, while software engineers mostly aren't.

[organian]

I think "software engineers aren't really engineers" is putting "real engineering" on a pedestal that is borne of ignorance. Hillel Wayne's engineer interviews were eye-opening on this: https://www.hillelwayne.com/post/are-we-really-engineers/

[RGamma]

Programmers calling themselves software engineers suddenly is a very recent phenomenon (barely a decade). Dunno who pushed that, but it's mostly basically (cognitively difficult) Lego at this point.

That said, it's also on the order of a hundred years younger a discipline and our theory is not so well developed.

[halostatue]

Try longer than my career (approaching 30 years in the business), often pushed by the business and kicked into high gear with the rapid need for development resources with the combination of Y2K mitigation and the first dot-com boom.

Yes, there are a lot of "developers". But there are also software engineers, even if our engineering craft is less-well developed by the standards of civil engineering or mechanical engineering. I understand engineering organizations (like those in Canada) who oppose the use of the term "software engineer" because there's no common code of practice or standards in the same way that those who wear the iron ring claim is incorrect.

I think that we, as a profession, need a code of ethics (and the ACM has a good one, https://ethics.acm.org/code-of-ethics/) and the application of software in certain cases should absolutely be regulated the same way that the various physical engineering practices are (healthcare, AI, finance, legal applications) so that there are consequences for the businesses and potentially the software engineers involved with those businesses when they cause harm (see sentencing guideline software in the US; see the contract that developed the Royal Mail "audit" software that could never work as advertised; see the rampant fraud that is crypto; see the abuse of generative models to software-wash copyright violations).

But the lack of regulatory bodies does not mean that there's not a practice of engineering involved, it just means that there's no regulatory body that governs said practice.

[mb7733]

> Yes, there are a lot of "developers". But there are also software engineers, even if our engineering craft is less-well developed by the standards of civil engineering or mechanical engineering. I understand engineering organizations (like those in Canada) who oppose the use of the term "software engineer" because there's no common code of practice or standards in the same way that those who wear the iron ring claim is incorrect

Just to clarify, there's no issue in Canada with "software engineer" specifically. "Engineer" is the protected term, and you have to be licensed to use it. So the issue applies to calling yourself any kind of engineer without being licensed.

If you are a licensed professional engineer in the software field, you can refer to yourself as a software engineer. This is just uncommon because there are not a lot of programs that grant BEng in software, the licensing is rarely relevant, and most people take CS anyway.

[fragmede]

> cognitively difficult Lego

Ah yes. Meanwhile, my friend who's a mech-e at a car company starts from scratch on every single last project, never reusing components, and also machines every component from scratch because there's no such thing as McMaster or any other vendor. When he works on a project, the physical parts never ever fit together like Lego. It's not like he'd use calipers or something to do what's called measuring (twice!) so that things fit together.

There are plenty of places to demand more rigor from people writing software before considering it engineering, but reuse of parts, and having them fit together nicely is a weird one.

[batch12]

My dad called himself a 'computer software engineer' in the early '90s. I don't think it's only a decade old.

[contrarian1234]

In the 90s it sounded pretentious and people used to joke about it. In the early days of Google they tried to label themselves as engineers to set themselves above the rest of silicon valley. It was a way to try to signal that their work was somehow more technical

[paulryanrogers]

Engineers used to mean seige-machine builders. Language will evolve.

[unmole]

> barely a decade

Yeah, no.

[s1artibartfast]

I have a different take. Engineer is basically synonymous with application physicist. Someone why applies the laws of physics to achieve a goal. I don't think this is so much a pedestal, or why some software engineers are passionate. Is being a computer scientist somehow negative?

[sterlind]

I think of applied physicist as something very different, closer to science than engineering. The kinds of people who research new battery chemistries, or the techniques to unlock new semiconductor process nodes. Basically, scientists do hardcore research and expand the field, while engineers apply the techniques and formulas that the scientists have discovered, and craftsmen combine prepackaged modules built by engineers for a job.

So an applied physicist discovers the light-emitting diode. An electrical engineer designs an LED light panel. An electrician wires light panels into a home.

Likewise, a computer scientist discovers NFA reduction, an engineer uses it to build a regular expression compiler, and a developer writes a regex to validate email addresses.

[fsckboy]

An electrician who designs a complex light panel using 120VAC for use in a habitable or public building needs to submit the plans to the building department to get a permit and certify that it's not a fire hazard. You need to be a Licensed Engineer™ to do certain levels of certification.

People certified to be licensed engineers didn't necessarily graduate from a School of Engineering at a famous university that is also filled with physicists and mathematicians and English literature. Instead they need to study, learn, and pass the tests that legally certify them as Licensed Engineers™ to keep us all safe. It's much of the same material, overlapping, but not the same. They're less likely to consider themselves ready to move over to building rocketships to the moon on the basis of their bachelors degree.

This is the source of all the debate about who is an Engineer and who is not. Licensed Engineers don't want to consider unlicensed engineers as engineers. People who went to universities and had to study a dose of liberal arts along with control theory to get their "Engineering degree" don't want to consider the choo choo Train Engineer™ as an engineer.

In the US there is a bit of academic snobbery around, it's not universal but, University of Michigan is harder to get into academically, and a little more high falutin'. Michigan State is a bit more plebian but more practical. University of Washington vs. Washington State, same thing, and so on. The licensed engineers are more likely to come from the State school, the unlicensed engineers more likely from the University of. Both want recognition for their training, which makes sense.

I'm exaggerating for effect, but this is the issue. Whether software engineers are engineers is a minor skirmish on the flank of this larger war, both because there are no certifications for computer engineers, and because mathematicians are not engineers and programming languages can be studied from a mathematical perspective or from something closer to Electrical Engineering.

[crdrost]

I liked these interviews but I do find the result kind of... apathetic? I feel like you can read these and just come to a sense that nothing is engineering because everything is amorphous, which is not (I think) Hillel’s thesis but he doesn’t really want to anchor the discussion in principle because he is fundamentally asking for opinions.

For a more principled approach, I would say (as one of these “licensed engineers who has not done as much actual engineering”) that engineering as I have seen it kind of has three really major themes:

• Prototyping/building/creation. Tinkering. I guess the reason we don't talk about this is that everybody finds it trivial? But when you talk to ChemEs and they discuss optimizing pipelines for chemical processes you do see that it can get a little abstract so it's worth pointing to as a baseline.

• An underlying scientific theory that guides the models used. Building stuff has happened since way before science but engineering is clearly a postscientific endeavor, “here’s the underlying mechanical principles of how this works.” This is probably the sketchier principle in how we talk about “is this software design really engineering,” we tend to not have a firm scientific understanding of the problem domain of building software. Some things like CAP theorem, patch theories in version control (Darcs, Pijul), distributed consensus algorithms, TCP/IP, I would say really rise to that challenge and say something hard-learned about real systems. Things like OS kernels also have so much trial and error, so much prototyping that it feels like “yes you really did do enough hypothesis-test-reëvaluate cycles that the result embodies a model of the problem domain that counts as a scientific understanding.” But a lot of our work is just gluing systems together and that seems more “electrician” than “electrical engineering.” Now, science uses math, so people think of engineering as highly mathematical, I am not sure that it has to be. Whereas I do think it has to be scientifically based.

• The last big thing that I think we don't talk about enough is risk assessment. The reason that we’re doing all of this science and math to build a bridge, is so that we can assess how strong it needs to be to just barely survive the peak loads that it will ever have, and then double that strength just in case.

I think that when we say “not all programmers are doing software engineering” a good proxy for that is looking at, first, do you have a scientific model of the sorts of approaches that you can do; and then, do you use it to assess numerically the kind of loads that your system will come under up-front and design accordingly—writes per second, queries per second—and set realistic targets and choose caching and consensus and whatever else to achieve those and measure that you have... Or do you work via crude heuristics, “we use Kubernetes so I'm sure it will scale later, we do ‘best practices’ so we don't have to think about those,” and related kludges where we can comfortably say you're just tinkering rather than being principled about it.

And then, this reveals that maybe you don't need to be doing engineering, maybe you really do just need to tinker in the problem space while you achieve better product-market fit. Maybe you are doing science rather than engineering, and that is okay. Like, the idea that you are going to launch the next space shuttle with your reliability, I am sure that makes for a very energized, focused workplace, but it's not a precondition, it's not the only way to get there.

[renewiltord]

True. We’re scientists. Replication is important! :)

[fhd2]

"Empirical science" sounds better than "have you tried turning it off and on again?", doesn't it.

[monista]

I read is as a reference to https://xkcd.com/242/

[tmpz22]

> True. We’re scientists. Replication is important! :)

Yes replication:

Oops we got hacked. I wonder what happens if we write insecure code again.

Oops we got hacked. I wonder what happens if we write insecure code again.

Oops we missed a deadline. I wonder what happens if we underestimate again.

Oops we missed a deadline. I wonder what happens if we underestimate again.

[sophacles]

When did software estimates ever factor into deadlines? I have always found that my estimates + a bit of padding are generally correct. Then management just picks an arbitrary due date that has nothing to do with programmer estimates.

[nly]

Plus nobody estimates on timescales anymore. We all use sprint points.

[alpaca128]

It isn't difficult to find non-software projects that overshot deadlines by years and costs by tens of millions or more, just to still have a leaky roof. Including, whether you believe it or not, engineering work.

[mock-possum]

Wow somebody’s salty

[wruza]

Why not hire hardware engineers to write software then?

[s1artibartfast]

Because software development isnt an engineering task.

Engineers are good at building bridges, and artists are good at making paintings. That doesnt mean it is a good idea to have the engineers paint paintings.

[defrost]

It might help to learn a little more about Engineering.

Leaving aside the four splits, Civil, Mechanical, Electrical, and Electronic with the obvious corollary that few Engineers build bridges, I'm reminded of my first student Engineering project back in 1983 (ish).

Building a sheep shearing robot - hardware and software, with no pre existing libraries of control software, etc.

https://research-repository.uwa.edu.au/en/clippings/how-nece...

https://www.cambridge.org/core/journals/robotica/article/abs...

https://www.youtube.com/watch?v=6ZAh2zv7TMM

A great chunk of software was written by Peter Kovesi .. a mechanical engineer still working on computer vision projects today: https://peterkovesi.com/projects/

You sound more than a little ignorant of the breadth and depth of talent in the world and more than a little inclined to believe that people can be boxed up and ring fenced by your particular world view.

No sheep were harmed in the making of this robot. Sheep literally fell asleep when secured.

[ganzuul]

To artists, engineers are artists who are good at math.

Art is for everyone. Painting is a special form of art. Math makes for beautiful art, so download LibreCAD and free your mind.

(Speaking as an ex. IT guy, ex. CNC machinist who is attending art school at the age of 40 as a form of rehab.)

[stronglikedan]

Software engineers for critical systems would like a word.

[gretch]

Yeah it makes no sense. Like, you build an airplane and clearly the airplane needs both it's software and it's hardware in order to fly.

Somehow the people who made the hardware are engineers, but the people who made the software aren't engineers.

[wruza]

That’s the point. It’s not software developer’s fault that things are the way they are. Anyone with strict engineering discipline or whatever is welcome to create software the right way.

[gerdesj]

I learned ForTran whilst studying Civ Eng. back in '89 - '91 . Notice the two digit year - you software lot gave us the Y2K snag 8) It seems rather silly these days when terabytes are trivially available but when every bit, byte and nybble costed rather a lot, it nearly made sense.

If software techies/engineers wish to push back, may I suggest: Tay bridge, Tacoma Narrows, Millennium bridge and concrete cancer. Comet commercial jet airliners and the many snags that lead to fillets and rounded corners on ships int al. Do we count Titanic as "user error" or inappropriate expectations exceeded?

[QuadmasterXLII]

Building as practiced by hardware engineers is not linear in number of unique components. Building as practiced by software engineers is, at a terrible price.

[smt88]

Software engineers are cheaper and more plentiful

[wruza]

Cheaper?

[tom_]

Try it and report back!

[kd5bjo]

Or perhaps that nobody had the common sense to call a tow truck, so that they can get down the mountain without relying on a field repair to a safety-critical system.

[slingnow]

This makes a lot of assumptions about how far into the wilderness they were, time of day, accessibility of the roads, cell phone signal, and so on. To just hand wave and call it "common sense" is silly without the rest of the context.

And for me, 100 times out of 100 I'm taking the capable guy who can fix the brakes on a trip like this over someone who's first and (likely) only instinct is to call a tow truck.

[atq2119]

As long as we're overanalyzing a joke, it's Switzerland. There isn't really a lot of wilderness there ...

[kridsdale3]

This is true. I spent a week hiking the mountains, where I often could see exactly the same environment that has existed for millions of years. But at all those times, a hut serving beer and warm soup was always an hour's walk away.

[tigen]

NIH syndrome

[s1artibartfast]

Not invented here is the tendency to avoid using or buying products, research, standards, or knowledge from external origins. It is usually adopted by social, corporate, or institutional cultures. Research illustrates a strong bias against ideas from the outside.

[toast0]

Sounds like they were already down the mountain. Stopping to call a tow truck while traveling down the mountain would involve having working brakes, which the scenario suggested wasn't the case.

[lostlogin]

No, it was a modern car and an unusual set of circumstances lead to a software bug occurring in the regenerative breaking. It needs further testing on that incline, at that time, in that weather with that weight in the car.

[bozhark]

Was it pulling an F-150?

[quickthrower2]

It is almost as if it is the closest profession to what they really needed: a roadside mechanic.

Also the story is unfair on the manager. The manager would call everyone in to have a war room meeting on how to fix this urgent production issues. They’d give a quick overview of the problem the open it up for the experts to talk. While the tech whizzes are talking they would order pizza or yum cha or something for the team.

[FrankoDelMar]

Turn the car backwards and use forward engine power to slow the descent ;) or engine brake with the parking brake set and hope for the best

[mock-possum]

If you could click ‘relaunch’ and the car would miraculously reappear at the top of the hill and repeat the event, allowing you to freeze time at the instant the brakes failed, then pull apart every piece of the car so you could precisely observe the failure in real-time, in slow mo, and in reverse - to pinpoint exactly what the problem was

You’re saying the power to do that makes software engineers ridiculous or impractical?

Engineering inside a digital space gives the kind of debugging abilities that would be straight up miraculous in a physical disciple. If I have one thing, and I want to make ten more of those to test in ten different ways, it’s literally just CTRL+C, CTRL+V. Let’s see a mechanic do that.

[brandensilva]

Right with software we have abstractions and flexibility. With hardware they are grounded more to the physical capabilities of the hardware.

Of course software is also limited by hardware capabilities but we can code whatever we want on that hardware as long as it fits within the provided specs.

[frutiger]

> "Well," said the software engineer, "Before we do anything, I think we should push the car back up the road and see if it happens again."

Only the brakes don't work - the engine still does. Why would they need to push the car uphill?

[mewpmewp2]

It's preferable the fuel state stays as it is. How do you know it's not the amount of fuel otherwise?

[cgriswald]

Presumably the engine was only idling during their decent if the only thing that slowed their car was 'miraculously' grinding the car against the mountainside.

So, using previous records, they should estimate fuel usage during the decent. Then they should walk to the nearest fuel station, purchase fuel, and walk back. During that time, they can calculate the amount of fuel that will evaporate while they have the gas cap off and the amount of fuel that will stick to the walls of the piping between the gas cap and the fuel tank. This way when they return to the car, they can put in almost exactly the amount of fuel that was consumed during their harrowing stop.

This presumes the fuel station has the same mixture as they have in their tank. Otherwise all bets are off and they should simply give up.

[ganzuul]

OBVIOUSLY, you could have solved the problem with motor braking. The driver is not going to accept fault until there is conclusive evidence of the their wrongdoing, but you can't let the team know you are going to repeat the test again but with a different driver because then they will invent objections to pushing the car up the hill.

[kridsdale3]

Turn the car around 180 degrees facing up. Coast down the hill in reverse and control your descent with the throttle.

[pests]

Reminds me of the Family Guy episode (I think) when Peter and Lous are both running for Mayor (or whatever) and were going to a debate. Peter had his brakes cut and when he arrives says "Sorry I'm late! Brakes failed" to which the response was "Shouldn't you have gotten here sooner?"

[starlevel003]

That was a Simpsons episode. S9E22 Trash of the Titans.

[pests]

Ah thanks, damn. Mixed up my adult animation. I swear I can picture the entire scene as Family Guy characters in my head though.

[xboxnolifes]

The brakes failed, but nothing claimed that they will fail again. So, it's suggested to run the test again.

[frutiger]

Of course but they could run the engine instead of pushing the car.

[rnk]

You are assuming it goes backwards or uphill. Better test that with a unit test.

[ganzuul]

"Magic", "More magic."

[buttercraft]

I would close all the windows and restart it.

[Elucalidavah]

> and see if it happens again

The "re-run to reproduce" isn't even the most peculiar part of software engineering; it's "we don't look at what has been tried before".

In the OP story example, there's this part: "One time we added ventilation holes to reduce heat, but they were just big enough for wasps to nest in". In a ideal world, the hardware engineers are supposed to know to not have any holes larger than a few millimeters, and other such things. Whereas the software engineers are (yet) not supposed to know much of anything like that. The most prominent example I can think of is "remember to add an index to the database when adding a new type of query to the app", as load testing that would catch it tends not to be done on each and every release.

[amelius]

I think it is possible to end this story in three possible ways, where each will be in favor of one of the professions.

[geraldhh]

please, go ahead

[wizzwizz4]

This story feels quite different without the context of the story this thread is about.

[oefnak]

Or they would say: go fast and break things!

[weikju]

Missed chance for a pun:

Go fast and brake things!

[kriro]

Let me retell this tale...

"I know," said the department manager, "Let's have a meeting, propose a Vision, formulate a Mission Statement, define some Goals and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way."

Knowingly the hardware engineer and the software engineer looked at each other. "Actually the car is fine, but let's pick a driver that knows what they are doing this time. You simply don't know how to use the breaks and were randomly steering left and right while thinking you're on track, management guy."