Comment by akiselev | Hacker News Reader

Comment by akiselev | Hacker News Reader

Parent Full thread

The important part of the professional certification like PE or MD is the liability that comes with it, which means that the professional has a lot more agency. A construction firm or hospital can't really force their professionals to do anything because the consequence is criminal prosecution (and a lot of legal liability for the employer).

Bring a software engineer into a courtroom as an expert witness, and the jury's eyes will glaze over. Bring in the PE who told their firm not to cut that corner, and the hammer comes down hard.

Even if the certification for software engineers starts as barebones as knowing what WASP is, it still provides an avenue for the feedback mechanism to work (the rules "written in blood"), so that the entire industry can study and learn from what happened, instead of this mess we have now, the peak of which is postmortem blog posts. Even now we have plenty of examples of regulatory frameworks where the regulations adapt to the field like the FDA where you've got a huge spectrum ranging from diagnostics to medical devices of which where are many classes, and drugs where every clinical trial can be tailored to the exact nature of the disease.

Wasp the defunct PL group from washington.edu or wasp as in owasp or something else entirely?

I have been a professional software developer for decades and worked in several roles where quality and security were at a premium but I have no idea what you mean by WASP. And yet you described it as "barebones" - an interesting illustration of the problem here. Real engineers have many years seeing the hard way what actually works. In software we don't have that kind of consistency and shared understanding of how to reliably get good results yet.

In my experience, good software engineers are often better "engineers" than those working in more physical disciplines, because they get a lot more practice. But traditional engineers have a far better culture when it comes to testing and validation. Since the cycle time is longer, and the cost of mistakes is higher, analysis and testing are generally baked in from the beginning. In software, it's easier to skip that stuff. But software engineers who do get indoctrinated into that culture learn most of the same lessons that traditional engineers do (i.e. how can a component be tested and maintained? what makes for a good design?) and the speed of development means they get more exposure to those types of challenges in general.

In my experience this works both ways too. Good engineers working on physical projects have picked up on some of the useful practices that good software developers have adopted for maintaining progress in the face of ambiguous requirements until they can be clarified and allowing as much flexibility as possible without necessarily compromising quality in the meantime. I believe these relationships can be summarised as something like "Good people keep open minds and learn from what has worked well for others".

The problem for regulating software development is still who gets to formally determine who the "good" people are. This kind of thing should clearly be objective and evidence-based but what useful evidence do we have available?

In physical engineering disciplines there are often clearly evident problems if something was built without being adequately specified by the responsible engineers. In a disastrous case a bridge might literally fall down but you're also going to see that a bridge wasn't designed properly if it's distorting in ways it shouldn't under loads that it should be able to support. There are lots of experienced engineers who have proven records specifying buildings or planes or ships that need to not break using established and peer reviewed techniques.

In software we can all agree catastrophic failures that result in loss of life or half the Internet going down are obviously bad. For something controlling a life-saving medical device or the launch authorisation system for the nuclear missiles we can probably all agree that the answer to what quality level we want in the software is "the best quality we can achieve". But those systems have unusually serious consequences if anything ever goes wrong and probably also very high development budgets that can justify such an extreme position on quality. In general we don't have clearly defined levels of software where different trade-offs between cost and risks and other factors might be considered reasonable and acceptable. Nor do we have well tested and universally accepted standards for how to reliably achieve a specified quality level.

> The problem for regulating software development is still who gets to formally determine who the "good" people are. This kind of thing should clearly be objective and evidence-based but what useful evidence do we have available?

There is zero useful evidence because there is no one to collect it.

The Institution of Civil Engineers was founded in 1818, after decades of random civil engineering societies in Britain doing the exact same thing we are now (running around like chickens with their heads cut off). It wasn't until after the ICE's Royal Charter a decade later that civil engineering began to get really systematized into the "real engineering" we know today and that charter effectively established them as a regulatory body that allowed that to happen.

There is zero useful evidence because there is no one to collect it.

I'm not sure that is entirely true. There have certainly been a few people who have attempted to study what did or didn't work in industrial settings - either pure academics or people working in industrial research labs. But I agree that currently we have nowhere near enough data to form robust conclusions about almost anything in this field and I think this is the strongest argument that the industry is not ready for any kind of licensing and regulation regime.

Reply on news.ycombinator.com