What are the kinds of things real engineers do that we could learn from? I hear this a lot ("programmers aren't real engineers") and I'm sympathetic, honestly, but I don't know where to start improving in that regard.

▲

roughly 7 hours ago | parent | next [-]

This is off the cuff, but comparing software & software systems to things like buildings, bridges, or real-world infrastructure, there's three broad gaps, I think:

1) We don't have a good sense of the "materials" we're working with - when you're putting up a building, you know the tensile strength of the materials you're working with, how many girders you need to support this much weight/stress, etc. We don't have the same for our systems - every large scale system is effectively designed clean-sheet. We may have prior experience and intuition, but we don't have models, and we can't "prove" our designs ahead of time.

2. Following on the above, we don't have professional standards or certifications. Anyone can call themselves a software engineer, and we don't have a good way of actually testing for competence or knowledge. We don't really do things like apprenticeships or any kind of formalized process of ensuring someone has the set of professional skills required to do something like write the software that's going to be controlling 3 tons of metal moving at 80MPH.

3. We rely too heavily on the ability to patch after the fact - when a bridge or a building requires an update after construction is complete, it's considered a severe fuckup. When a piece of software does, that's normal. By and large, this has historically been fine, because a website going down isn't a huge issue, but when we're talking about things like avionics suites - or even things like Facebook, which is the primary media channel for a large segment of the population - there's real world effects to all the bugs we're fixing in 2.0.

Again, by and large most of this has mostly been fine, because the stakes were pretty low, but software's leaked into the real world now, and our "move fast and break things" attitude isn't really compatible with physical objects.

▲

bostik 6 hours ago | parent | next [-]

There's a corollary to combination of 1 & 3. Software is by its nature extremely mutable. That in turn means that it gets repurposed and shoehorned into things that were never part of the original design.

You cannot build a bridge that could independently reassemble itself to an ocean liner or a cargo plane. And while civil engineering projects add significant margins for reliability and tolerance, there is no realistic way to re-engineer a physical construction to be able to suddenly sustain 100x its previously designed peak load.

In successful software systems, similar requirement changes are the norm.

I'd also like to point out that software and large-scale construction have one rather surprising thing in common: both require constant maintenance from the moment they are "ready". Or indeed, even earlier. To think that physical construction projects are somehow delivered complete is a romantic illusion.

	▲	Exoristos 5 hours ago \| parent [-]
		> You cannot build a bridge that could independently reassemble itself to an ocean liner or a cargo plane. Unless you are building with a toy system of some kind. There are safety and many other reasons civil engineers do not use some equivalent of Lego bricks. It may be time for software engineering also to grow up.

▲

taikahessu 7 hours ago | parent | prev | next [-]

> 3. We rely too heavily on the ability to patch after the fact...

I agree on all points and to build up on the last: making a 2.0 or a complete software rewrite is known to be even more hazardous. There are no quarantees the new version is better in any regards. Which makes the expertise to reflect more of other highly complex systems, like medical care.

Which is why we need to understand the patient, develop soft skills, empathy, Agile manifesto and ... the list could go on. Not an easy task when you include you are more likely going to also fight shiny object syndrome of yours execs and all the constant hype surrounding all tech.

▲

macintux 7 hours ago | parent | prev [-]

What concerns me the most is that a bridge, or road, or building has a limited number of environmental changes that can impact its stability. Software feels like it has an infinite number of dependencies (explicit and implicit) that are constantly changing: toolchains, libraries, operating systems, network availability, external services.

	▲	1313ed01 7 hours ago \| parent [-]
		That is also something the industry urgently needs to fix to be able to make safe things.

▲

skydhash 7 hours ago | parent | prev | next [-]

Act like creating a merge-request to main can expose you to bankruptcy or put you in jail. AKA investigate the impact of a diff to all the failure modes of a software.

▲

Mistletoe 7 hours ago | parent | prev [-]

What is the factor of safety on your code?

https://en.wikipedia.org/wiki/Factor_of_safety