Earlier this year I wrote a piece interviewing ex-traditional engineers to compare and contrast with software engineering. [1] Pieces like this were a lot of my inspiration: there's big difference between how we conceive of trad engineering and how it's actually practiced. Couple of misconceptions from this piece:
> Engineering is less risky than software because engineering experiences fewer constituent component interactions. While minor changes to one part of a car's structure can easily affect the crash robustness of another, it would be unusual for a design flaw in the dome light to cause intermittent engine stalls. In a home construction project, you would have to work pretty hard to make a toilet flush every time someone rang the doorbell.
While software has more "component interactions", each component is also more consistent than physical components can be. One example: using stainless steel screws on an aluminum plate can cause your building to collapse. [2] That's a bit of an extreme case, but many fields of engineering, like electrical and chemical, regularly struggle with small changes leading to wild differences in the emergent phenomena.
> The final reason that software is more difficult to get right than engineering projects concerns midcourse design changes. The physical world is not as malleable as the insubstantial world of software and, consequently, clients simply have lower expectations. Congress does not go to NASA halfway through a moonshot and ask them to go to Mars instead. Most engineering projects are able to actually use the waterfall design method: determine functional requirements, design, implement, test. For most software projects, this is a recipe for disaster.
Very few projects are built using "waterfall", and everybody I interviewed had horror stories of requirements changing mid-construction. At least a couple people I talked to had to move buildings after they were built. One ex-industrial engineer worked for Boeing and his sole job was to manage midcourse design changes.
One story I didn't put in the essays: a naval engineer worked on an oil rig. They needed to add a new piece of equipment, but it would have caused the rig to violate certain liveability constraints. It could stay on for short periods of time, but not 24/7. So they built a nearby platform to store the equipment, and then airlifted it in by helicopter every time they needed to use it, and airlifted it out immediately right after.
> Writing software is most similar to writing fiction novels.
Almost everybody I interviewed said that writing software was very similar to their old work in engineering. A lot of people I've talked to outside the project said it was most similar to cooking, or planning an event, or doing surgery, or whatever. Most fields are like other fields, which is why interdisciplinary studies teach us so much.
> Engineering is less risky than software because engineering experiences fewer constituent component interactions. While minor changes to one part of a car's structure can easily affect the crash robustness of another, it would be unusual for a design flaw in the dome light to cause intermittent engine stalls. In a home construction project, you would have to work pretty hard to make a toilet flush every time someone rang the doorbell.
While software has more "component interactions", each component is also more consistent than physical components can be. One example: using stainless steel screws on an aluminum plate can cause your building to collapse. [2] That's a bit of an extreme case, but many fields of engineering, like electrical and chemical, regularly struggle with small changes leading to wild differences in the emergent phenomena.
> The final reason that software is more difficult to get right than engineering projects concerns midcourse design changes. The physical world is not as malleable as the insubstantial world of software and, consequently, clients simply have lower expectations. Congress does not go to NASA halfway through a moonshot and ask them to go to Mars instead. Most engineering projects are able to actually use the waterfall design method: determine functional requirements, design, implement, test. For most software projects, this is a recipe for disaster.
Very few projects are built using "waterfall", and everybody I interviewed had horror stories of requirements changing mid-construction. At least a couple people I talked to had to move buildings after they were built. One ex-industrial engineer worked for Boeing and his sole job was to manage midcourse design changes.
One story I didn't put in the essays: a naval engineer worked on an oil rig. They needed to add a new piece of equipment, but it would have caused the rig to violate certain liveability constraints. It could stay on for short periods of time, but not 24/7. So they built a nearby platform to store the equipment, and then airlifted it in by helicopter every time they needed to use it, and airlifted it out immediately right after.
> Writing software is most similar to writing fiction novels.
Almost everybody I interviewed said that writing software was very similar to their old work in engineering. A lot of people I've talked to outside the project said it was most similar to cooking, or planning an event, or doing surgery, or whatever. Most fields are like other fields, which is why interdisciplinary studies teach us so much.
[1] https://www.hillelwayne.com/tags/crossover-project/
[2] https://www.fastenal.com/en/70/corrosion