When I listen to his talks I get the feeling that his brand of professionalism is aimed at people operating at the craft end of the profession and less so at the developers who are working more like professional engineers. I wouldn't have written this post at all except that the article in the Atlantic was very clearly talking about safety-critical software and I thought Uncle Bob's response wasn't quite fair.

I don't think that there should be a huge divide in the industry. Good software engineering practices are useful to everyone. An individual practice may or may not be something good for an engineer, a team, or an organization to adapt, but it comes down to cost versus benefit. As you move closer to the safety-critical end of the spectrum of software-intensive systems, the benefit of doing something outweighs the cost, especially when you start talking about human lives at risk if there is a failure.

I'm not sure I understand what you mean by communication problems. Examples?

Someone says "Scrum", I think exactly what is described in the Scrum Guide, but they are referring to their adapted process that's based on the Scrum Guide. Sometimes, "design" is used to mean planning out the structure and organization of software ("big design up front" or waterfall design before code mindset), but writing code is a better example of design in software. There's no universally (or even widely, perhaps) accepted definition of what a "unit" (in the context of a unit test) is - some people use words like method or class to define a unit, but I prefer Wikipedia's definition that it's the "smallest testable part of an application".

The problem with licensing is what do you require the developer to know and/or do to hold a license? The science in our profession is pretty thin. Is agile in or out? Is TDD in or out? Is it okay to write safety-critical software in Python? Is it okay to create a design without using UML? See the problems?

These are the problems. I think the first sentence of the Manifesto for Agile Software Development is very applicable, even to people who aren't following any of the other principles: "We are uncovering better ways of developing software by doing it and helping others do it." We're all learning here. We can learn from the people who have gone before us and from each other, but we're all in a different situation with regards to customer expectations, legal or regulatory requirements, tools and technology. There's no silver bullet software process or framework, so it's hard to build a licensure test.

NCEES already offers a PE exam in software engineering. The IEEE's Guide to the Software Engineering Body of Knowledge also exists. And there are common things that software engineers should be able to talk about. However, due to the nature of the field, software engineers tend to specialize. I'm familiar with a good breadth, but my depth is in development processes (although I write code, I was also a process improvement engineer at my last job and a Scrum Master at my current job) and project management. There's plenty of important stuff that I would need to do research on to tell you what the current state of affairs is. But the key is that my education gave me exposure to be able to go out, do that research, and understand it (or know that I need to do more background research and then understand it).

But these problems are only compounded by the communication problems I identified above. Licensure is usually handled by laws. Laws define what work requires a license and work that does not require a license. If we can't craft laws that are very clear about what kind of work requires a license and what kind of work doesn't and then provide current and relevant content on the exam, then we won't be in a better place.

Thomas, as someone who has worked in highly regulated industries, where do you see things going in the future?

I think a few things.

We need to get better at ethics and ethical decision making. We've been fortunate with respect to lives, but also look at Uber's Greyball or the Volkswagen emissions scandal. Software is everywhere and companies have access to vast amounts of data about users - location data, payment information, the websites visited, and so on. Even things that aren't safety critical (where failure can lead to injury or death) need to consider the public good and respect the rights and privacy of users.

We need to get better at communication. All of us, no matter where we work, should be talking (to the extent possible, of course - not sharing proprietary information or other sensitive information) about the way we work, why we work that way, and the tools and technology that facilitate our work. I don't think we should expect everyone to work in the same way, but I think more people should understand what is expected of engineers in regulated industries and why the regulations are. I think the regulated industries have a lot to teach everyone else about good practices, even if the set of processes and practices as a whole doesn't make sense for everyone else.

Specifically in regulated industries, I think that the regulations and auditors need to be more open-minded about alternative ways to achieve the requirements and objectives of the regulations. My current company is very agile and has managed to tie an agile mindset to the requirements. My previous company was trying to move in that direction when I left, but it's an uphill battle when everyone is used to or expecting a certain thing and you give them something different. Organizations should be encouraged to try to look at new good practices and find ways to incorporate them into their way of working and to disseminate information about the way they work outwards.

Yes, I see the communication issues now that you've given some examples. This is, indeed, a common problem in our industry.

Regarding training and licensing, I once dated a doctor going through her residency and that's a very interesting model (this is in Canada - other countries are likely different). Doctors must graduate from medical school but then during their residency, they do rotations in all kinds of areas so at the very least they know how the different specialties work. It doesn't matter if you are going to be a family doc or a brain surgeon, you rotate through an array of specialties, even though you spend most of your time learning your specialty. Then at the end of your residency you need to be recommended by your superiors to take 'the board' exams. If you pass you become a licensed doctor. If not, you may be given a chance to repeat the year and retake the exam or they might decide you don't have what it takes and end your career right there.

That would be an interesting licensing system for software developers who wanted to be licensed. Of course, we don't have an institutions to support such a system but imagine if we did for a moment. Think of the potential quality of the developers that made it through something like that.

Not only do we have the institutions to support that kind of system right now, the educational systems that produce software engineers are sometimes very different than those that produce other engineers, doctors, lawyers. Not all software engineers go through traditional college or university education. And even those that do may not go through any kind of formal education in computing. However, these people are just as capable of being great software engineers.

Part of the reason for this is the low barrier to entry. The tools and resources needed to design and build software products are much more accessible than tools and resources needed to build many other types of engineering products. This, plus the easy-to-obtain educational resources make all of this possible.

Any kind of system needs to consider people who don't have formal education in computing.

Good points. We could also add non-native English speaking to the list as well.

Does anyone have direct experience with the training offered by the Software Engineering Insitute at Carnegie Mellon? They offer courses that appear to be semi-on-point here. I've looked at these courses before but they are government/defense focused and I work in a small business so I didn't get far.