Exactly, and that's the problem. Writing software isn't engineering (it ought to be—my opinion and that of many others). Read this (things are actually worse since it was written):
www.researchgate.net/profile/Wayt-Gibbs/publication/247573088_Software%27s_Chronic_Crisis/links/0046353b4cb57cc197000000/Softwares-Chronic-Crisis.pdf?
That said, I think we sometimes tend to overestimate how structured projects like bridges are, and that almost everything we have discovered about software projects applies there too, just to a less extend - delays, changing requirements, unrealistic planning, last moment extra requests etc. etc.
OK, so what happens when the weak link in the chain in building a bridge or other critical structure like a plane is the software that helped design it?
So-called software engineers want their cake and eat it too. They aren't prepared for the rigors and discipline of real engineering yet they expect to take equal part (and claim credit) in engineering projects.
That's how we get disasters such as the 737Max and I'd bet London to a brick it won't be the last.
I'm not alone in holding this view: https://www.fceia.unr.edu.ar/asist/gibbs00.html
Structures are one-and-done projects with engineers having access to concrete data on material strength, load calculations, etc.
Software projects are never ending, always chasing ever changing requirements. There are no comforting rules of math and physics to fall back on. There are no "load and safety" calculations that another software engineer can perform on a program to verify its integrity.