When Software Development Becomes a True Profession

I describe the software profession as an industry of amateurs. I say this because we do not yet have many of the things that a true profession has, such as a defined path of entry or good apprenticeship opportunities. 

“Uncle Bob” Martin estimates that the number of professional software developers doubles worldwide every five years. If this is true, then on most teams, there are much fewer masters than apprentices.

So, how do software development teams figure out the right things to do? The answer is that, largely, they don’t. A lot of teams flail around trying to create something of value, and they experience great difficulty doing it. They can search Stack Overflow and find quick fixes to immediate problems, but that doesn’t show them how to fix style and overall structure. The result is that they can make the computer do things, but their code is difficult to understand and hard to extend.

I blog a lot about quality in software, and I use terms like cohesion and coupling. I recently got a comment on one of my blog posts where the reader was quite upset that I didn’t define these terms and that he could find no industry-standard meanings for them in a Google search.

If your doctor told you she couldn’t figure out the name of the thing that encases the brain, which she thinks is called a head but when she looked up “head” in the dictionary, she found that the word also means “toilet” or “the front of a line,” you’d probably think that doctor was unfit to practice medicine. Obviously, many words have multiple meanings, and some words have specific meanings to a specific industry. Virtually every industry has its own jargon, so why are people surprised that the software industry does as well?

The word cohesion in its common usage means how well things are stuck together, but that's not how software developers use the term. In software development, it means that an encapsulated entity, such as a class or a method, is about one thing or has one purpose or reason to exist. It has a singular focus, and it follows the single responsibility principle.

I’m sure if you looked up the single responsibility principle on Google, you would find many thousands of hits from many people who have many differing opinions about what the principle really means. But to understand the meaning of the term, we go to the source, and the source of the single responsibility principle—as well as the four other SOLID principles, as we refer to them—is Robert C. Martin (Uncle Bob again), who defined these terms in his book Agile Software Development: Principles, Patterns, and Practices.

If somebody writes a blog post that expresses the opinion that germs come from some alien planet, it doesn't make it so, and it doesn't negate the body of knowledge that medicine has accumulated for thousands of years. It's just someone’s opinion. And that's the difference between a true profession and an industry of amateurs: Amateurs have opinions, but professionals draw on a common body of knowledge. If you don't know what that common body of knowledge is, then guess what: You're not a professional. It's really that simple—except that finding that common body of knowledge in the profession of software development can be quite challenging.

You don't get to graduate medical school without knowing the basics of medicine. You don't get to practice law without passing the bar exam. But you can get your undergraduate degree in computer science without ever writing good code … or a programming job without a degree at all! People who can type some things into a computer and make it do something suddenly think of themselves as professional programmers.

What constitutes “good code” in software development? If you ask a hundred programmers, you'll get a hundred answers, and this again points to the fact that we have no industry standards and practices upon which to evaluate our decisions. If you gave a hundred doctors a set of common symptoms to a disease, they most likely would all diagnose that disease correctly. In software development, we use terms like legacy code and technical debt, but we don't really have common definitions for the antipatterns that cause technical debt.

It's not that they don't exist—they do. It’s just that they're not widely known.

Medicine and the law have been around for centuries, but software development is barely sixty years old. And the way we practice software development today is different from how we practiced it even twenty years ago. So, not only is it a new industry, but it's a moving target. We haven't figured out yet what's important and what’s unimportant, but I'm sure this was true in other disciplines at their outset. Imagine what medicine was like in its sixtieth year—certainly not nearly as sophisticated as it is today.

There’s a great TV series called The Knick about a hospital in the early 1900s, and—spoiler alert—at the end of each episode, the patient nearly always dies. The doctors didn’t understand how to treat illness like we do today. Something similar is happening in the software industry: We’re still figuring it all out, and as a result, we get things wrong. But that’s slowly changing.

Unlike thirty years ago, when I was first learning to write software, we have many good books available that are must-reads for today’s developers, including another one by Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship, and Refactoring: Improving the Design of Existing Code, by Martin Fowler.

These books go beyond the beginner level and discuss issues important to professional programmers. Additionally, the agile community is constantly discovering new approaches and techniques that you can learn about first by going to a conference. And please don’t forget the vast amount of information available for free from blogs and websites like this one.

The software industry is young, and we will be figuring things out for quite a while. Software is radically different from anything else in the world, and it'll take time for us to explore and understand this whole new domain. But as we do, we will be learning enormous amounts about ourselves and the nature of information in general, and these things will expand human consciousness dramatically.

Computers have changed all of our lives. They’ve changed industries and business. They’ve changed the way we think about ourselves and the way we access knowledge. But the greatest changes from the software industry are yet to come, and they won’t be in the form of a new program or a faster computer. They’ll be in the form of a new story, because that’s what ultimately means something to us humans—stories. And like all meaningful stories, they’ll be about us.