Full Discussion (Is Uncle Bob serious?)

A few random thoughts...


Software professionalism is a really broad topic. What Robert Martin presents is such a narrow sliver of professionalism. When you say "professionalism", I think about things like defining the disciplines (of software engineering, computer engineering, computer science, information technology, and other related fields), education and certification, bodies of knowledge and educational curricula, roles and responsibilities in the workplace, licensure, ethics, and so on.

I've been turned off by a lot of what I've read from Martin, especially some of his writing on what he considers to be a viable professional code of ethics, women in computing, diversity in tech, and other matters of professionalism and professional practice. Although he's made contributions to the agile methods and good construction practices, Martin isn't someone I would necessarily turn to for information about professionalism or professional conduct.


I'm also not entirely convinced by the argument that processes are sufficient.

I've worked in both aerospace/defense and pharmaceutical software (both highly regulated industry) doing both software development as well as process improvement. We have quality system requirements and have things like independent quality assurance, traceability from requirement or feature request through code commits and manual and automated test cases, mandatory peer review, and the need to collect objective evidence of our processes.

Something that I don't see from external sources is a push to improvement. Often, these regulations are incredibly slow to change. So when new advancements come out, it takes a very long time (measured in years) to update regulations, if they even get updated to include changes. And often, these companies working in the safety-critical space are larger more bureaucratic organizations. This means that it's harder to change the internal processes.


I find myself agreeing with Dr. Nancy Leveson's comment that the emphasis is on coding and testing. But, as far as technical work, that almost makes sense. Everyone writes code (and everyone should be writing some kind of tests). However, not even is working to captured requirements or has to worry about traceability or so on.

I do agree that a broader look at the tools used to build software is good. And this is full lifecycle tools. Requirements through code into deployment. Traceability, static and dynamic analysis, visualization, forward and reverse engineering. All of these do have their places. I think we're caught in a cycle. The people who need these tools to meet requirements are relatively small, so the tools don't improve. But in order to catch on, they need to be easier to use and more streamlined.

The only tool that I'm not convinced of us formal specification languages and model checkers. But then again, I've never worked at the extreme end of safety-critical software. I wouldn't be surprised if there is a subset of software-intensive systems where this makes sense, but I just haven't experienced it yet.


I think that there are two things that are really hard to wrestle with that we, as software engineers, still need to deal with.

First is communication. I think it's really hard to communicate, especially across industries and domains. There's no good common terminology for sharing how we work. The same words and phrases are used to mean different things to different people. Likewise, the same concept can be represented by different words and phrases. And that's just if everyone is speaking English. It's hard to talk about the way we work when it takes a lot of effort to define common concepts.

Second is licensure. Especially in the world of safety-critical systems, there's no good licensure for software engineers. Part of this goes to how hard it is to communicate with each other. Part goes to the educational background of software engineers. Part goes to the sheer breadth of the field and all of the different environments and domains. I'm opposed to requiring blanket licensure of software engineers, but I do think that this is something that we should be able to talk about to make sure that individuals don't take shortcuts or provide cover for those who do. But it's a near impossibility until we can actually talk about our discipline and come to an understanding between people who work in regulated and critical environments and those who don't.

I think it's almost unfair to say that Uncle Bob is representing the interests of all software developers. 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'm not sure I understand what you mean by communication problems. Examples?

Licensing is interesting. Doctors do it, engineers do it, lawyers do it but so do plumbers, electricians, etc.. I don't see any reason why we couldn't do it. In fact, I think we should do it. Not everyone but if you want to work with credit card data or personal information like medical records you need a certain level of certification. If you want to work on software that controls hundreds of millions of dollars, that's another level. And if you want to work on safety-critical systems, you need to be licensed for that too. There could be all kinds of levels.

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?

Thomas, as someone who has worked in highly regulated industries, where do you see things going in the future? As we try to build self-driving cars, add AI to everything, add IOT to everything, build all kinds of robots, and generally control more of the world with software, how do we:

  1. make this software safe as it gets more and more complex?
  2. increase the speed / reduce the cost of this kind of software?
  3. train enough software developers in the techniques required to safely build these kinds of systems?
  4. move promising techniques and/or tools into these highly regulated industries to improve the quality and cost profile of these projects?

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.

Good points, Thomas.

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.

code of conduct - report abuse