You keep using that analogy. I don’t think we are what you think we are.

The smartest software architect I ever met once told me, “If you get your nomenclature right, you’ll likely get everything else right, too.” Maybe that’s why things are so wrong in software development.

Managers keep calling us something we’re not. They are, to trigger the woke, “mis-professioning us.”

For decades managers have persistently pressed a formulaic imprint of sports onto programmers. This is invalid nomenclature. Of course, managers also tried to brand programmers with the illusion that they build bridges, or cars on an assembly line. Managers have tried to portray programmers as members of a craft guild who build objet d’art.

Programmers aren’t any of the things managers call us, but we’ve been called the wrong things for so long that it gives outsiders license to treat programmers as if they were the wrong thing named in the wrong nomenclature. They would love to treat programmers as a team, a guild, or an assembly line. So they do.

Programming is not sport. Programmers are, therefore, not a team. While programmers must certainly be skilled, they are not members of a guild. I am a scientist, and I can assure you that programmers are not scientists. Programmers don’t build bridges; they aren’t engineers. We don’t toil on a production line in spite of how hard many scrum lords force the fit. I don’t care what nomenclature – stolen from other professions and misapplied to programmers – you want to use… It’s Wrong!

And most especially, programming is not a management process easily performed within structures of other professions. We have our own professional world and we flourish when working, properly, within it.

Once taken seed, the error grew

In some cases the error grew from ignorance. I’ll accept that management doesn’t know what we do or what we are. Maybe the impedance mismatch between expectation and reality deluded management into thinking they were right, anyway.

This is familiar to the sales breed as “fake it ’til you make it.”

In other cases, it was so the manager could dismiss programmers as esoteric; or imply that the effort of understanding our profession was without value sufficient to merit the effort.

And this is just tyranny.

Those chimeric delusions laid on programmers by non-technical managers never fit, but those attached epithets prevail. It was wrong, but it stuck.

In many ways, the Agile Industrial Complex, hardly agile and suffering from the same misnaming as programming itself, thrives because these wrong names allow the contamination of Taylorism in software development.

It was wrong. It remains wrong. Why shouldn’t we just “let it go,” and roll along as we always have? Because we must break out of error if we ever wish to fully succeed. Don’t let it go.

Programmers aren’t any of the things managers call us, but we’ve been called the wrong things for so long that it gives outsiders license to treat programmers as if they were the wrong thing named in the wrong nomenclature. They would love to treat programmers as a team, a guild, or an assembly line. So they do.

In many ways, the Agile Industrial Complex – hardly agile and suffering from the same misnaming as programming itself – thrives because these wrong names allow the continuation of Taylorism in software development.

The path from such a virtual Waterloo is littered with the castoff baggage and casualties of four decades of these communications errors. We must demand better. We cannot continue suffering management and project failures originating from this kind of foundational error for another forty years!

What should we call “those in a group of programmers?” Managers want a shortcut.

Terms of Venery

Venery is an archaic word for hunting. Even modern society knows some of these terms: flock, herd, or gaggle. Terms of venery have a long and storied history that every erudite scholar should know, at least rudimentarily. The original (and very limited) set of terms of venery can be found in The Book of Saint Albans, originally published in 1486 by St. Albans Press. No gentleman of the time failed to keep this collection in his library.

Terms of Venery are worthy of study, even today, if for nothing but the novelty of thought.

The clever still try to imitate terms of venery in our own times. “Team” is one such term that serves one purpose but utterly fails to deliver the necessary understanding. It connotes a group who need a coach; who requires that someone watch them for their work and skill. And managers happily leap into the role of overseer.

By applying the wrong term of venery to programmers, managers (through inaccurate assertion) quickly leap into the only role that gives them authority over them. But what is the correct term?

I submit that we have insufficient professional experience with programmers to truly name them by any proxy. There are many reasons.

Firstly, there’s no such thing as a programmer. (Be patient with me on this.) Even the term programmer is a term of venery for a whole bunch of allied skills. It is broad, and therefore, too general. Were we to dig down, we’d find a whole bunch of different jobs our managers just want to lump together as “programmers.”

Pah.

Call us by our names. But only call us by our names if we can all agree on the definition of the name.

An incomplete list (with no overt hierarchy) may include the following:

• Coders
• Architects
• Software Developers
• Designers
• Data Professionals
• Programmers:
  • Machine language
  • Compiler developers
  • Front-end
  • Database
  • Framework
  • Library
  • Embedded
  • etc.
• Web Developer
• Application Security Specialist

… and there are so many more.

Like Larks, I think we could speak of “an Exaltation of Architects.” Perhaps “ a Murder of Data Professionals” might be appropriate. What about “an Intrusion of Project Managers?”

Unfortunately for the terminally negligent, I don’t think we could approve of referring to the whole of the allied fields as a “knot of programmers.”

Then what should we call the people who create the instructions that machines follow to automate complex or tedious tasks that deliver business, medical, scientific, and even organizational solutions?

Call us by our names. But only call us by our names if we can all agree on the definition of the name. For example, I see job listings for an Engineer III. I have no idea what an engineer (III) is or does. And you don’t either.

I recently had quite a conversation with a headhunter about the term, architect. You see, I have no idea what an architect is. So I told the headhunter that.

Never be honest with headhunters. They aren’t used to it.

He was shocked. I was supposed to blindly go along with the charade and agree that I was an architect because I’m experienced and erudite. But I turned the tables. I asked him to describe an architect. He described a project manager.

I describe a software architect in specific terms. I use the only valid example available: the structural architect.

A structural architect takes three major factors into consideration:

1. The topology and geography
2. The structural materials desired and available
3. The residents and their purpose

From that, a good structural architect will design and propose a series of ideal building structures for the client. A software architect should do no less.

The Software Architect should consider these three main factors when designing a software solution:

1. The available hardware, communications, and network topology
2. The languages and tools available and acceptable to the customer
3. The users and their problems that require solutions

Trust me. My definition of a software architect is not acceptable to this one recruiter. Maybe it will be unacceptable to all recruiters. (Regardless, I told him I was not his definition of Architect. Maybe I’m not my definition of architect.)

But you can easily see where failures in nomenclature immediately lead to damage in communications: the wrong job, the wrong framework, the wrong language, the wrong solution, or the wrong design.

How can you persist in erroneous nomenclature now that you know how wrong it is?

If you must call us something other than what we are, be generic. I like “group.”

(Other choices might include department, division, assembly, detachment, core, or unit. Feel free to choose your own names, but be sure they don’t connote that we are anything that we are not.)

Perhaps our profession has matured to the acceptance of classification rather than nomenclature. Like biology, maybe we should be classified by kingdom, phylum, class, order, family, genus, and species.