Uncle Bob Weighs In

July 1, 2009 — Posted by Scott Bain

Recently at the Rails conference, Bob Martin served up a very provocative talk: "What killed Smalltalk could also kill Ruby." There has been a fair amount of controversy about this particular presentation, most notably from the Smalltalk community who consider themselves to be not-at-all-dead. They point out, for instance, that Smalltalk was not free "back in the day" and Ruby/Rails is, and that this makes more of a difference than many of the factors Bob was referring to.

For my part, I don't care all that much whether one language or another is in vogue as much as I care how the technology is being used and specifically how our profession is or is not maturing as a result. Bob said that we were not a profession in the past but are now. I tend to agree with him. He also equated the notion of a profession with the concept of disciplines which I also totally agree with (this should not be too terribly surprising to anyone familiar with the book I wrote recently - Emergent Design: The Evolutionary Nature of Professional Software Development - and if you note the particular engineering practices we choose to teach at Net Objectives).

So I'm with him on this, but I think there were a couple of things missing in his equation.

Being in a profession means many things. For one, there are standards and practices that all professionals are expected to follow. Lawyers save all documents. Doctors sterilize all instruments. But it also means that there is a defined way to enter the profession, and a set of support mechanisms that help the professional to succeed. The disciplined professional is provided with a helpful context in which to make the decisions that drive his/her activities, increasing the likelihood of success, and thus gains a fundamental degree of confidence in those decisions. FeetFire

In other words, there's a lot in it for the professional to be in a profession -- guidance, which leads to confidence, which leads to a sustainable career. It's not so much about holding our feet to the fire and making sure we follow procedures (and slapping our wrists when we don't). Rather, it's about providing us with what we need to be extremely valuable to the people we serve. Isn't this ultimately what we all want?

In addition to this, the notion "professional" changes the expectations of those we serve.

For example, when I go to my attorney, I generally don't try to instruct him on how to solve a particular legal issue; I present him with my concerns and ask him what he thinks should be done. I don't dictate to my doctor how to solve my health problem; I describe my symptoms and ask her what she recommends we do about them. I also don't tell her how long it should take to solve the problem. How would I know? I trust her to know, if it's at all knowable.

When the customer thinks "professional," it changes their expectations regarding the interaction. I submit that, as software developers, there are a lot of times when we are told things we should be asked, and that this happens not because we don't consider ourselves to be professionals, but rather because we are not regarded as such by those we work for. But if we don't think of ourselves as professionals, why should they? And if they don't, should we be surprised when they tell us "this should take you two days"?

Furthermore, is it surprising that these arbitrary schedules are often at odds with reality? People who don't create software are understandably less knowledgeable about how it gets created, what the difficulties are likely to be, and how to best overcome them.

We need to start thinking of ourselves as professionals and to start behaving as professionals for many good reasons, but among them is that we will hopefully be seen as professionals by others, and this may lead them to ask us rather than tell us many of the things that can make a critical difference: what architecture to use, what process to follow, how and when to test, how to best document a specification, etc…

Of course, if we succeed in getting them to ask us these things, we'd better be prepared to give good answers. If my lawyer messes up, I hold him responsible… and I should. If we ask our customers to trust us at such a high level, they will expect us to deliver on that trust.

I submit that the things we elevate, as a society, to this level of responsibility and trust are the things we consider to be critical to our survival. Software didn't use to be that way. In my earlier career (in broadcasting), failure in my software did not stop the business from succeeding. We still stayed on the air. For many (most?) businesses today, software failures seriously hamper core activities and in many cases can stop the business it its tracks.

Put another way: agree or disagree with Bob on the idea that software is a profession. Whether it is or not, I think it needs to be and we need to get together on this conversation. What would a software profession look like? Should we have the AMA of software? Should software developers be licensed? How should developers be trained, what should the path of entry be to this profession?

Let's talk about it as a development issue and as a process issue


Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Scott Bain

Scott Bain is an consultant, trainer, and author who specializes in Test-Driven Development, Design Patterns, and Emergent Design.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban