> Here's a neat idea: maybe regulating software engineering like other engineering disciplines is actually overdue? Yet at the same time, failure rate will never be zero.
Please could you describe this more? I’m intrigued.
I don’t know anything about this and what systems or mechanisms are used to regulate engineering, so any links or simple explanations are appreciated!
If you want to e.g. build a bridge it needs to be signed off on by an appropriately licensed and qualified Professional Engineer. Essentially the parent comment is saying there should be streams of software development that meet the requirements to become a Professional Engineer. Then places e.g. medical, defence, power plants could say "we need software that's been signed off by an engineer" and have assurance that the final product is of a known quality and unlikely to have any life and safety endangering defects. They are strongly incentivised to only sign off on properly engineered projects as they can be held personally liable e.g. if a bridge fails and kills someone.
An example of the level of quality that would be delivered is the software that ran on the space shuttle. See this article https://www.fastcompany.com/28121/they-write-right-stuff for an insight into how it was developed and the practises required.
I don't think all software developers should be software Engineers, but being able to lead a team to enforce quality (and not sign off on poorly thought out "MVP" crapware) would guarantee that the software that came out of that team would be reliable and well designed. It would be good for software engineering overall to be recognised as a legitimate branch of engineering. Unfortunately it seems like most of the industry does not have the sort of rigour needed for engineering tasks.
> It would be good for software engineering overall to be recognised as a legitimate branch of engineering.
I think the only way this could happen would be if SWE only used waterfall or some similar kind of practice. Agile and the like might be able to be tweaked to work, but even there...
The problem in software is that you can basically "start in the middle" of something and work your way outward; start coding something, get the design details later and refactor.
You can't do that with a bridge or other regular engineering work. You have to plan, design, multiple sign-offs, etc - then build, and you can't build it randomly or a component here and there then fit it all together (well, you can to an extent, depending on the project and design), and if anything changes - well, in a real project it can't change much, not without a lot of money and time being lost.
Several years back there was a series of commercials on TV, I think for an insurance company, which showed (using CGI effects) "impossible building strategies" - one showed a huge scaffolding structure and cranes building something like the Great Pyramid from the top downward (for instance); I think another had some kind of skyscraper being built from the middle outward or something of that nature.
That's essentially SWE applied to regular engineering - or at least, that's how it feels at times. Now tack on Agile and other practices, and it gets 10x worse. Actual engineering is a strict discipline, starting with almost set-in-stone practices along with a lot of hard-won knowledge about materials and mechanics (books filled with tables and diagrams), that are then all used to inform an engineering design, which is then tested and retested in simulation, perhaps coupled with scale models that are also tested, and the plans changed and signed off by multiple other engineers, etc - long before it ever gets to building the thing.
And then that thing is built in a very specific and strict manner; I won't further belabor the point.
Even with all of this, sometimes things fail terribly.
Today in software, we have a ton of tools and practices we are constantly trying - and despite all of them, at least from my perspective - things really haven't gotten much better than they were 20-30 years ago. I would say that widespread use of software versioning tooling and testing frameworks, etc (plus automated build and deployment) have made some of it better - but even after all that, we still seem to be making the same number of bugs and errors that we had before (and rather than a QA department usually, we've farmed this out to the end user for the most part).
So while I'd love to see SWE become more like regular engineering practices (with the selfish request that I and others like me could be "grandfathered" in, as I don't have any kind of compsci or comparable degree, but I have been doing this for 25+ years) - I just don't see it happening for the above rational and reasons.
I could be wrong, though (and if anyone has a counter argument, please post it - I'd love to read it)...
Please could you describe this more? I’m intrigued.
I don’t know anything about this and what systems or mechanisms are used to regulate engineering, so any links or simple explanations are appreciated!