Today, I came across this tweet from Thomas Fuchs:
So I started wondering about what makes software engineering different from civil engineering, and how we could make more reliable software. I replied with:
And then thomas came back with
So...
- Are there things we can learn from civil engineering to make software more reliable?
- Are there inherent differences that make creating reliable software harder than creating reliable constructions?
Latest comments (20)
I'm a civil engineer and have been for 10 years, I just got into developing and my view is you should unfollow him.
Hey... This is Kiev city! Isn't it?
This bridge ("ΠΠΎΠ΄ΠΎΠ»ΡΡΠΊΠΎ-ΠΠΎΡΠΊΡΠ΅ΡΠ΅Π½ΡΠΊΠΈΠΉ ΠΌΠΎΡΡ") being built since... OMG - from the 2003 year! They still can't finish it >.<
I don't know, to be honest. I just googled "bridge construction" in Google images, using a filter to only take images that were licensed for reuse. But I think there might be an analogy here with time estimates in software development.
Well, yeah - it is it.
Here is how it looked in 2017:
vesti-ukr.com/kiev/225202-chto-mes...
And itis still there :-)
They are writing it might(!) be finished at 2020, i.e. after 17 years of the building.
Software still needs to run on physical hardware. Code can absolutely be 100 precent perfect to the job it is intended to do. There logical structure and code could be flawless, but then the underlying hardware may fail in an unexpected way. This doesn't mean total system failure either, it could be as simple and small as a single bit flip in a critical section in RAM. And this bit flip could be caused by an external source.
jakepoz.com/debugging-behind-the-i...
Computers are more complex than civil engineering projects, because even though the physical system is smaller, there are significantly more pieces and people involved to make it happen. Just take a look at the number of contributes to which ever OS you're using, then the application stack on top of that.
Actually it's the opposite there is a predictive model for hardware service life.
That they called bathtub model which is based upon the service period of the hardware.
Which just says that the beginning operational life and ending operational life for the hardware, requires more maintenance to keep it at optimal safety standard.
This is the reason during the space race, Soviet space equipment is mostly manual based due to this predictability of the hardware service life for safety reasons.
From my understanding some industry standards use the same model to justify your safety on the hardware failure risk that is installed with your software like the IEC 61508.
There is another school of thought which is a mathematical predictive model for software is possible but it is up to the interpretation of safety and compliance to a specific standard.
Which differs from industry and the government who is adopting that particular standard.
Which my safety systems professor, who had taught me the standards always joke on.
He will never ride a self driving car even if he was given a million dollars since in terms of safety standards it is not safe by any account due to unpredictably of software.
There is a lot what we may learn from mature engineer disciplines, I think. However, I would take a closer one - electronics. There is more logic involved as in software engineering.
I've wrote an article how we could take over the art of compose things together from electronics creating higher level abstractions. We call this principle Integration Operation Segregation Principle. This only works well at the end if the composed modules does not know each other. A point which is impossible as long as subroutine calls are used for composing. We must get rid of sub routine calls at least for composing SW modules. We call this Principle of Mutual Oblivion.
Details: bit.ly/2yJBnzX
For what it's worth everything in civil engineering structurally focuses around factors of safety.
Dead loads at an additional 40% and live loads at an additional 60%.
Maybe there is something to learn about building in safety to your code or infrastructure from the outset.
What your talking about is called "safety critical systems".
Which is the type of software used in ships, planes, nuclear power plants, cars and anything that will cause a lost of life or equivalent of more than 1 million USD if that piece of software fails.
We actually have that standard in place.
But it comes down to can you afford in building that piece of software as usually the higher the safety rate you want.
You will usually go bankrupt by building that piece of safety critical software due to compliance & rigorous testing.
You can take a look at this if your interested in it.
This is a super niche industry that unless your planning to work for Tesla, Spacex or NASA.
It won't be applicable for the majority of industry.
Even my university professor who teach this standard, has industry partners coming in to listen in the lectures on that particular standard.
en.m.wikipedia.org/wiki/IEC_61508
If you've ever looked closely at licensing terms on software you might notice a phrase similar to: "The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications."
Software is built to different standards, and if lives are at stake then the standards are correspondingly higher.
I'm sure that different standards also apply in civil engineering
Survivorship bias: for every hundred year old structure that exists today, how many have previously collapsed, rotted away, or burned down?
en.wikipedia.org/wiki/List_of_stru...
The surviving structures are generally also well and actively maintained to fix the issues surface.
When we maintain software (by fixing issues) people often complain that software is not as stable as building and bridges.
Yes, good point.
Type systems (in pure FP), category theory and formal methods.
You can just restart a buggy program so there's not much of a business case for proof systems. I do see their value myself, but common perception is against me om this one.
Foolproof software would probably cost 3x as much.
FP type systems have saved me a great deal of time in the past, so I'd say "citation needed". It takes some time getting used to them so people wrongly assume it's a time-sink.
If you look at the situation in practice, the tools we have are still underdeveloped and underused. A lot more could be done for near-0-cost security/certainty.
Well 3x was more for the sake of the argument, I don't have citation and I do agree that over the last years a lot of improvement has been done in the way of testing and best practices (CI/CD easier than ever). But even that will take time before it is adopted properly from all teams developing software.
We are still a young industry compared to Civil Engineering field and we are still evolving and learning.
I have heard praises on FP so I better get my hands wet in the subject.
If you have to do tests to verify your program (not everything can be proven after all) then the cost would indeed skyrocket. For instance, you need to account for every combination of inputs (a potentially infinite set) and behavior may depend on some hidden unknown variables.
You may be interested in one of my old posts about the curry-howard isomorphism the comments are pretty good too. I should also point out though, that even pure FP languages don't really exploit this property. For instance when dividing by 0, but also good old overflow problems.