[TheCapn]

I imagine we'll see more of it as time goes on. Management without a technical background depend on the expertise of their workers to get things right. They can only manage work so far but if there's bugs they can't understand or don't know how to find root cause of they'll have to point the finger eventually.

Besides, if a whole industry of software devs are going to insist on calling themselves engineers I hope they adopt the ethics and responsibility other engineers are required to undertake.

[Zigurd]

> if a whole industry of software devs are going to insist on calling themselves engineers

It's hard to see around this enormous straw man. Starting with the poor applicability of engineering-oriented project management systems to software creation, there are many reasons not to call it "engineering" even when practiced at the highest levels.

[CaptSpify]

> Besides, if a whole industry of software devs are going to insist on calling themselves engineers I hope they adopt the ethics and responsibility other engineers are required to undertake.

What ethics and responsibilities do non-software engineers have that software engineers don't have?

[stevenbedrick]

In many countries, certain kinds of engineering are licensed and regulated professions. For example:

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

It's officially a Big Deal in some branches of engineering- structural, mechanical, and civil come to mind. My city just built a new bridge over our river, and the engineers who signed off on its design and construction were doing so under a certain legal framework that is designed to ensure that the design was done using proper methodologies, appropriate tests were conducted, etc. If the bridge fails due to shoddy design, those engineers will personally face certain professional and legal consequences. That same legal and regulatory framework gives the engineers certain protections should management try and make them cut corners on the design or testing (in theory, anyway).

People have been debating for years about whether there ought to be a similar legal framework for software engineering. There are plenty of good arguments on both sides of that discussion, IMHO, but the sorts of situation described by the original article would fall squarely under the "pro" side of the equation. I can easily envision a world in which, for software that is critical to a public safety function of government, states had to buy software written by bonded and licensed engineers. Presumably, under such a framework, a licensed software engineering company would have to have a system in place such that their "hit by a bus factor" would be >1- i.e., they'd need to have sufficient documentation or process in place to enable any single engineer to go on extended leave without preventing critical bug-fixes from taking place.

This is obviously something that any developer would recognize as a "best practice", but that in practice is often infeasible due to organizational constraints. The advantage to a system of regulation and licensure would (in theory) be that it would empower engineers to demand such practices be in place in their organizations, and would incentivize companies to set themselves up to enable such practices. In theory. As the saying goes, "in theory, there's no difference between theory and practice." Hence why this has been an ongoing debate in the software world for decades.