Discussion on: Is Uncle Bob serious?

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.