a treatise on the hubris of labeling people by: Geo. Jeffry

“All professions are conspiracies against the laity.” :: George Bernard Shaw

Layering silicon and other metals to corral currents in our itty-bitty layers triggered an explosion more powerful than any unleashed by those pointy-headed scientists out in the 1940’s New Mejican desert. It’s just that nobody heard it until decades later when they felt it.

Transistors reduced the family-room Wurlitzer to a totable, affordable teenage fad. Figuring out how to fabricate thousands of transistors in the same space previously occupied by one triggered a bigger boom that sent us to the moon, taught us how to surveil everyone on earth, all at the same time, allow people standing on opposite sides of the earth to communicate, and built the biggest blight on the human condition since Eve baked up the apple pie and Adam ate a slice: the personal computer.

These advances triggered another response: the professional divorce between the traditional, 19th-century management style and the 21st-century bumpkin laborer.

Now the whole world had one language and a common speech. As people moved eastward, they found a plain in Shinar and settled there.
They said to each other, “Come, let’s make bricks and bake them thoroughly.” They used brick instead of stone, and tar for mortar. Then they said, “Come, let us build ourselves a city, with a tower that reaches to the heavens, so that we may make a name for ourselves; otherwise we will be scattered over the face of the whole earth.” :: Genesis 11

In the 19th century, managers had no problem with the bumpkin laborer, even if they spoke some guttural language among themselves (and a different one than the management elite learned in university). But after the shock waves of semiconductors and esoteric technical jargon pervaded the talk of the bumpkin laborer, the elite manager no longer felt quite so divine.

The bumpkin laborers were building bricks of silicon and layering them thoroughly, building calculating machines that would reach to … the heights of managerial control! Indeed, despite never quite making it to the heavens, the bumpkin laborers became the elite – speaking an educated language with a dense, confusing jargon unknown by the white-shirt management.

Although somewhat lesser deities than those they would aspire to be, management nonetheless struck on a daring piece of biblical confusion. Managers do not, did not, and will not understand the technical knowledge of the bumpkin laborer. They conspired, nonetheless, to confound the ability of bumpkin laborers to adequately establish peerage with other bumpkin laborers when separated by distance, ownership, or platform.

The demi-elite gave the technical bumpkins pet names: titles, they call them.

They chose to detail and disperse arbitrary and capricious titles among the bumpkin laborer that obfuscated – if not totally eliminated – any comprehension of their labor.  Now, two bumpkin laborers performing the exactly-same work at Amalgamated Incorporated bore entirely different labels from those at Corporation for Amalgamation.

Forty years on, the demigods seem to have a problem. As we speak and exchange ideas and titles, we bumpkin laborers are beginning to translate beyond the confusion. We know the difference between an apple and an orange; we don’t care what you name it.

We’re breaking the code. We know what titles mean most of the time. We can now, without them even knowing, anticipate their strategies.

In this sense, herein lies a primer on the subterfuge of management against language. It is not a conspiracy against the laity, but against the new elite: the technical specialist.

They Let Out the Smoke, Didn’t They?

I’ve known for decades that technical professionals and managers don’t speak the same language. But the preamble, only recently perceived, demonstrates that the titles we use for our roles, assignments, jobs, or positions on an org chart are not meant to inform, but to disinform.

Common management approaches substitute titles for authority. Rather than granting intellectual reign over their technical domain, management granted titles, like magic beans, to the former owners of their intellectual domain. The only magic in these beans were the slight-of-hand from the tricksters.

Common management substitutes titles for meaning. Titles, rather than conveying meaning, become the meaning. It’s called ”circular definition.” “A Jr. Dev is responsible for performing all the duties and functions of a junior developer.” Tricksy, as Smeagol would say.

As Barbie said, “Math is hard.” As the manager says, “learning what technical people do is impossible.” Managers like sports analogies because sports roles are very easy to learn and remember. They have titles: coach, assistant, official, etc. They give each other titles gained by attending three-day seminars and paying bribe money to enablers that then print out certificates on the HP laser printer that say things like: PMP, PCM, LSMFT, EGBDF, or PVNRT.

Software developers don’t attend three-day seminars hosted by obfuscation enablers. We just create worlds from chaos. The title for that is “software developer,” “programmer,” “coder,” or “Assistant Junior Night Development Support Apprentice in Training.” None of these convey what managers might understand: none of them have anything to do with sports, golf (which is not a sport but penance), frat parties, spring break, or terms regarding their family trust.

Talking to professionals who do things the manager cannot understand scares managers. The manager desires control and a lack of control triggers an inestimable fear. Management has always used hierarchies and charts to show authority and control. British royalty has titles. Managers want titles. Viscounts can rise to King! Professional managers can rise to CEO!

But what of the boorish, miserable peasants who work under the stairs and (out of sight, mind you) make sure all that sorcery we call computers do the work managers no longer know how to do? Never fear, good peasant. Peons get titles, too! (And you get a title and you get a title and you get a title and everybody gets a title!) It doesn’t matter what the title means, so long as someone writes the title in the org chart. Whover knows what a viscount is, anyway?

Invented titles – invented by the manager, always appear in a box (dashed lines sometimes, even), and always appear beneath the box in which the title of the manager appears. That’s because the manager who makes up the title, makes up the definition and selects the position on the org chart.

“When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean — neither more nor less.”

“The question is,” said Alice, “whether you can make words mean so many different things.”
“The question is,” said Humpty Dumpty, “which is to be master — that’s all.”
:: Lewis Carroll, Through the Looking Glass

Managers working with software developers could call us “kid,” “hey you,” or any insult they wish and we’d still do the work because we need the pay. We answer to “Rover,” “Spot,” and “who’s a good boy!?” These epithets are just as good – and maybe better than what we get, though.

Technical titles convey no information outside of the esoteric organization chart where that title occurs.

In my sense, this practice debases language and confuses anyone trying to communicate. I’m inclined to believe this is management’s intent. It is not an unintended consequence.

One must possess a mountain of knowledge and experience just to scramble through one more day of this technical skirmish. These precious, theoretical, invisible campaign ribbons we earn are like medals won in deadly conflict – dear to the wearer and revered by those who benefit from sacrifice in service. But only those of us who labor in the digital miasma can see them. Only we revere them.

In the 1980s Harvard revolutionized management by proclaiming, “you don’t need to know the bidniss, you only need to know the tools, pretty pictures, and buzzwords of management.” It was a lie then. It’s a lie now, but the Harvard MBA became the greatest prize for the executive bound for glory. MBAs didn’t graduate knowing how things worked. They didn’t graduate knowing how to design a bridge or build a house. They didn’t even graduate knowing how to keep a shrub watered in the summer.

They graduated with a document that proclaimed to all the world: “I know how to chart progress by motion, how to eliminate everything that isn’t motion, and how to make more widgets per hour with fewer strong backs. I know how to impress the stockholders!”

For those gentle readers playing along at home, this is a practice known as “Scientific Management,” popularized in 1911 by Frederick Taylor, a nearsighted mechanical engineer who fancied himself an innovator. He promoted this practice which then and now bears his name:  “Taylorism.”

[As a scientist, I must object to the misuse of the term, scientific. Taylorism is no more scientific than noticing that the cheerleaders dated hunky quarterbacks more than geeky honor students. It involves a big word called “empiricism,” which is used in place of science. Every time you ever read “empiricism” from now on, just insert “look-see” in its place. You’ll be smarter already.]

In whatever jumble of words available, Taylorism taught that workers should be focused on maximizing labor – given the inadequacy of their education or skills; and that managers should provide the most fatherly guidance because of their elite education and “look-see” experience.

Does this sound like the modern technical workplace of today? Not much has changed in 110 years, huh. Taylorism is, in truth, our daily bread. (And it creates a satirical mockery the greatest desire of all software developers, The Manifesto for Agile Software Development.

Like the disconnect between their words, there exists almost nothing in shared goals or mission between software developers and managers. In truth, we’re closer to enemies than allies. This is the genesis of the near-constant rally for team-building.

We don’t like to think of it this way, but software developers and technical specialists are in constant conflict with management. We have been since the ’80s. We remain so now. We only admit it when we don’t think anyone’s listening.

We reject reality and accept, then, in a faux gesture of unity: the titles managers and their attendants heave our way.

In electricity and magnetism, the physics class that caused the greatest lab excitement, we were constantly warned to match voltage for voltage, amperage for amperage, and impedance for impedance. College students fare poorly in following orders. When there’s a mismatch, the lab student was said to have let the smoke out of the component. And once you let the smoke out, you never get it back in. Managers have done this to our technical language.

Any Wonder Titles Don’t Mean Anything Anymore?

Maybe, a long time ago, when we applied the honorific of “doctor” to someone who graduated from medical school, a title meant something. It bestowed plaudits on a person. It reflected hours of study and focus, of dedication to a goal, and it elevated and separated a minute fraction of our mundane population above the norm.

Titles allowed us a shorthand for shared respect. Military ranks and academic fellows implied duty, honor, and basis for distinction. But like everything, titles became a commodity. The value of the honor or distinction had to be weighed against the ease with which the commodity could be obtained.

One of my own relatives received a mail-order Ph.D. from a post office box out of St. Louis, Missouri. Henceforth, she always introduced herself as “doctor.” The rest of the family cringed when she did this as we knew she was embarrassing herself because everything else that followed from her crackpot brain confirmed that she was a crackpot. (Res ipsa loquitur.) (I’m grateful it wasn’t in anything medical or technical.)

She wasn’t the first mail-order doctor. She won’t be the last. I shall, nonetheless, lay some blame on her for the market crash of the value of all titles, earned or bought. By the time this relative became a “doctor, every title, from King to “hey you” was already devalued. Titles are worth less now. In fact, they muddle all meaning, making having a title worse than not having one.

Titles don’t mean anything anymore. They assure the failure of meaning.

Maybe it started when garbagemen were reclassified as Domestic Waste Technicians or when we stopped calling Aunt Beatrice’s husband a bum and started calling him Permanently Leisured. As a kid I wondered why adults did this. They were teaching me that some folks didn’t have the integrity to express the truth. They also taught me that honesty hurt folks’ feelings if they’d gotten used to using lies as a salve for failure and disappointment. After a while it just seems easier to reject honesty in lieu of giving everyone a trophy; a practice which followed pretty quickly afterward, too.

Technology titles – from executive to data-reduction clerk, from books to people – were already a dime-store commodity by the time anyone spun up their first copy of “Zork!” Why we succumbed to even using titles in the technical ranks has always been a curiosity, but whether because we wanted to feel important or make others feel important, we awarded and granted titles to anyone and everyone in the software development business. We used to allow ourselves to be fooled by this. We don’t anymore.

We’re in a Lying Bidniss

I’m not out to offend, although I got used to it a long time ago. But I am as honest as the courts will allow. Technical bidnisses (a little Tejas lingo) are replete with con-men, politicians, cheats, liars, more than our fair share of Dunning-Kruger victims, idjit executive relatives, and the Holy Congregation of the Buzzword Flim-Flam Scam! (That’s “manager” to you and me.)

Any modern Diogenes could burn down a lot of candle wax looking for an honest man in our bidniss. I’m sure there are some. I’ve met one or two. (They mostly left the bidniss for lives of quiet repentance and work among lepers. I envy them.) Our language debasement makes our mockery of titles understandable. But interpretation of our titles based on lexicographic definitions are not now – and may never again be – understandable; as if they ever were.

Yet, titles abound. Meaningless titles. Big titles. Little titles. Tongue twisters. Lying titles that roll off the tongue like honey. They’re here. We can get around to blame some other time. I have my suggestions. We’ll put that off until later, though.

To this end, I thought I would offer some common titles and wax poetic (using Diogenes’ wax, no less) to illuminate the shadows our bidniss has made of the labels we take, purloin, acquire, or otherwise obtain from our mail-order diploma mills.

Enjoy while you cry in your favorite adult beverage. (Mine is coffee. I’m a wimp.)

Pretenders and Spectators

Rule: if you commit/push code to the repository on a regular basis, you are a software developer, no matter how great or small. Everyone else is a spectator. One of the best sport analogies (like those managers love to use because they understand sports and are witless in software) is of the stadium full of people. Twenty or so play on the field. 50,000 or so watch from the stands. Software development is a lot like this.

This section is dedicated to those who never contribute code during software development but pretend to be chums. Software Architects and Software Designers bear the brunt of my antipathy; but in a generous mood, I might admit there are times when those with pretentious titles actually contribute to the repository. It’s rare as hen’s teeth. But it happens

Be discerning. Many of those – even those who hold titles obviously intended to make you think of code – do no code. This is especially true for the Architect and the Designer. My own grace shown by implying that some may be coders expresses my mostly-unfulfilled optimism that, one day, all architects and designers will be mostly coders. I have lost that optimism, but the ideal this represents is, nonetheless, greatly to be desired. I have met the fingernails-dirty coders who bear the label of architect: once. I have met self-described fingernails-dirty designers (but have not witnessed this), but we might choose to be merciful.

Programmers are generally accepted as working in software development and contributing code regularly to the repo, even if their current corporate title obfuscates real meaning. (We’ll get to coders in a bit.)

But to begin, we’ll reserve our first painful excursion into these mires and swamps of what we’ll call, “the pretenders.”

Architect

I have an announcement. Do I have everyone’s attention? The Software Architect doesn’t exist. I know this comes as a surprise to all those narcissists who have the title. But after talking to enough label-bearers I’ve deduced this cold, harsh fact. (I will share as much of my data as the climatologists at East Anglia University have shared about their climate claims.)

Still, we have these imposters roaming the landscape and usurping the name. The ghost of Ada Lovelace knows I’d dearly love it if software architects really did exist. And if they did exist, I ask, “what would they look like?”

Janus, the Roman two-faced god of politics, had to look in two directions at the same time. True Architects have to have an additional face that makes them wholly unfit (or perhaps, more fit than the others) for politics. Needing three faces is the easiest aspect of software architecture.

The three faces of the software architect must simultaneously scrutinize the following:

1. The people for whom this software will be built,
2. taking into consideration the purpose for which this software will be built,
3. in the topology in which this software will be built.

Now you know why you’ve never met an architect. You’ve never met someone who concentrates on a software project from these principal perspectives.

In the profession from which our industry purloined the title, architects recognize that a skyscraper is out of place on the Iowa farm, that straw floors and mangers filled with oats would be uncomfortable dining rooms in grandpa’s house, and that for six months of the year, a solar farm would be unusable in the arctic.

For some reason, software architects seem intent on violating each and every aspect of their professional duty. That’s ‘cuz they’re told that being  an architect is just an overpaid project manager and for that kind of money, they’d better toe the line. If modern software architects share any “school” with modern structural architects, it’s the brutalist school, I’ll betcha! They’re not out to build. They’re out to tear down. Bravo! Software Architects. Bravo!

In a bad twist for the non-existent software architect, there are always competing purposes, people, and contexts. The three-faced, mystical achicreature must choose to be a villain to one and a hero to another. Balance can only exist in a hollyweird polyverse  where simultaneous and conflicting realities coexist at a wizardly whim. Stan Lee couldn’t make that plot line work.

I repeat. The (software/hardware) architect doesn’t exist. The title is a total sham.

Acknowledging that the title grazes about on the verdant pseudo-fields, someone says they exist. So, what are they and what do they do? Sometimes they’re senior developers encumbered with the burden of a complex project. It takes a certain arrogance and narcissism for a developer – regardless of experience – to agree to be responsible for a project for which insufficient thought, authority, and autonomy have been granted and to whom competent staff and client are withheld.

Some erroneously hold the title when the real title is “Choreographer,” or “Stage Manager.” Picking from a menu of options and deciding how each menu item will be presented at the table is not architecture. Still, using the right title would properly insult the staff. Nonetheless, when five competing groups have orders to collaborate, someone must negotiate and coordinate. That’s the job of the stage manager (for the whole) and choreographer (for the individual).

I’m not saying these roles are unimportant. I’m saying we’re calling them “Ursa” when we should be calling them “Pooh.”

I like to refer to architects as The Walking Dread. If they get close enough, they’ll eat your brain. (That’s what I’ve heard.)

Designer (front-end, application, database, system)

The ersatz architect (but I repeat myself) oft times relies on the “designer” for the detailed choreography; and especially the set construction. In reality, these folks are nothing more than “buyers.” Buyers go to the shows. They see the haut techno. They return home and rave about the new fashions. They pitch that the new fashion should be part of their fall line. Their idea of design is to sell someone else’s designs as part of their own collection. And they add their own flourishes.

Some designers talk about color wheels and pixels. We have designers to blame for the 837 different ways a user must ferret out how to find the main menu on an application. Some really annoying designers (it’s a real contest, innit?) debate this control library vs that control library and hold very emotional views on those things uppermost in their ignorance. (I don’t have to remind you that these are art majors at heart.)

But in a world where art majors stayed where they should be and served us bad coffee at overpriced latte shops, what would the designer do in software? Thanks so much for asking the question.

In the real world, software designers would be called Ergonomists. These people study physiology, psychology, and human factors to build intuitive, low-stress interfaces for the inhuman aspects of software. Ergonomists design cockpit layouts for mach-3 fighters, control layouts to safely monitor nuclear reactors, and even design seating to reduce the chances of lumbar injury in sedentary jobs. Each and every one of them is a hero. None of them work in software.

If we had ergonomists instead of designers, we would know that use of one color was preferable for reasons of psychological or cognitive response. Instead, we pay “design professional teams” a quarter of a million dollars for two “color palettes” chosen by their internal focus groups (read: interns). Did I mention it’s an art?

What surprises me is that we haven’t yet had a flood of board-certified Feng Shui Software Designers, promising to deliver chi balance in your energy centers for your software interfaces. I deduce that even grifters know when to stop grifting.

In this title, as in this profession, we have hope, though. Look to the iPhone and the iPad. Look at the Mac OS interface. Clearly there exist some remarkable ergonomists at Apple. Clearly, they need to help us discover what Apple ergonomists know that our pseudoscientific Feng Shui grifters cannot even imagine.

In this hope we must also acknowledge a market superiority that may not be the only market superiority Apple holds. (It is a pity that Apple products are seen as the realm of non-technical users of our technology. We get so many things wrong even when we see, clearly, with our eyes and intuitively with our minds, that some experts are better than others.)

Engineer (software, DevOps, Dev, Ops)

Engineers fabricate products. They draw certified designs, choosing materials with well-known and constantly documented physical properties that can assure the desired physical performance. Let’s carefully sneak through this definition with an eye on software.

1. Fabricate
2. Certified designs
3. Well-known physical properties

1. Nope.
2. Nope.
3. And nope.

I don’t think engineers exist in software development, either, now that we’re down to definitions.

We might (rarely, but sometimes) find the EE or electrical bench technician working with software developers on robotics, CNC, or communications software. I’d like a show of hands for the number of my readers who have worked in those industries. No hands. I see.

Firstly, we do not fabricate software. Software developers call software into being using our will, our words, and our courage. Materials are irrelevant. Tools are irrelevant. Platforms are irrelevant. The first software developers wrote instructions on paper tape in specifically-mapped zeroes and ones. And just like those days, the software was not the paper. It was the world the paper called into being.

Secondly, the management scam usurped the realization that no one tells software developers what they really want them to call into being with their secret words. There are no designs, much less certified designs. Certainly, twenty years ago there was a race of bespectacled social scientists who weaseled their way into the technical professions by claiming to document every requirement and change in a software development project.

We all recognize that this “failyuh tuh communicate,” as Strother Martin said in “Cool Hand Luke,” resulted in more failures than trying to get the rings around the little bottles at the carnival. Not to mention, this often tripled the work, quadrupled the cost, and led to more overruns than trying to land a 747 on a grass runway.

Lastly, we never discuss physical properties in software. One zero is pretty much as durable and usable as the next. I’m even told that it takes the same amount of space to store a one as it does to store a zero.

The properties we often reference in software have to do with the developers or the patterns or even the theoretical concepts of the proposed software. Not since 1994 has anyone asked if they can deliver the new version of the software on fewer than seven 3.5” crispy disks. (The answer was always, “sure,” until it wasn’t.) Now our engineers are in the cloud: a meta-meteorological phenomenon of lesser actual substance and physical content than anything the weather celebrity on the 6:00 O’clock news talks about.

After some thought I’ve relented to consider the burden of connecting all the pieces parts of any online platform to make it work as infrastructure. I accede that this might be labeled as near-engineering. These positions often require diligent study, but are not exchangeable between online platforms, so they become almost ecclesiastical and only relevant within the one religion. Still, I shall not (too much) in the future, deride those brave souls who inhabit the esoterica of the chimerical with the spirit of the engineer.

I'm not allowed to run the train,
The whistle I can't blow.
I'm not allowed to say how far
The train's allowed to go.
I'm not allowed to pull the brake,
Nor even clang the bell.
But let the damn train jump the track
And see who catches hell!

Scientist (data, software, application, system)

So far, we’re 0 for 3. Let’s go for the Bingo! I haven’t mentioned this title before. It is one I bear under my other title: Chemist. Calling someone who lives in the invented world of zeroes and ones a “scientist” offends every traditional scientist. I must, however, discuss their own linguistic blasphemy.

For those of us who made it to and through ninth grade, I remember distinctly that the scientific method was drilled into the sunburned 4H members and the wanna-be football stars, even if they were Texicans and, therefore, never expected to validate another hypothesis in rest of their entire “remember when” lives.

You can Google the scientific method yourselves. It will save me some typing. But I’ll append some ideas about science that Google probably won’t cover.

Dr. Ernest Rutherford, one of the first atomic physicists and winner of the Nobel Prize in 1908 for identifying the structure of the atom, said of science, “All science is either physics or it is stamp collecting.” While I’m a chemist and took some umbrage to his philatelic insult, he is right, you know. We have some physics on which we, even chemists, rely. But I’ll bet my silk pajamas that there’s no physics investigation in software science this side of the Restaurant at the End of the Universe.

Another curious requirement overlooked by folks who want to be called scientists even though they can’t derive the third integral of a chocolate chip cookie is that any scientific theory must be disprovable.

Did you get that? Any hypothesis must be falsifiable. Otherwise, it’s religion. Far too many errant title holders mistake empirical observations for science. In “Cars,” a referenceable source for many things scientific, Filmore says, “I’m telling you man, every third blink is slower.” Sarge responds with, “The sixties weren’t good to you, were they?”

Filmore’s observation isn’t measurable in that context and it certainly isn’t repeatable in the physical world to the goal of being disproven. Those who side with Filmore are just as wrong as those who side with Sarge.

And therein is a distinction between empirical observation and science. Most software scientists stop at the observation, leap to a conclusion, and think they’ve done “science.” They’re constrained like this because science (remember? this is about physics?) seeks to model and explain the natural world.

If anyone in the software bidniss thinks we’re dealing with the natural world, I’d invite them to step into that IDE and find out where the green letters come from.

If they’re not scientists, what are they?

I’ll allow that some are actually pretty good statisticians. Some are intuitive data analysts. Some just throw methods from the library on the wall to see which one makes the pretty chart.

Note: I started my programming misadventure because I was a chemist, and no programmer knew enough chemistry to automate the mathematical models used in our research. At no point, then or now, did I rear-end chemistry into programming and think I was then a software scientist. Didn’t then. Don’t now.

Developer (Programmer/Coder)

If there were still presses, I’d yell, “Stop The Presses!”

These poor, suffering schmucks exist! Hallelujah! We’ve finally found a real title for a real job! For whatever misguided reason, software developers decided they wanted to develop software, even though it is thankless, stressful, annoying work. “Did I happen to mention that your job is on the line here?”

This is my favorite title for those who, using sacred words and holy dance, call a new software creation into computer being. I’m not saying developers are like gods. They are more like Michelin Chefs, only they don’t need any meat or vegetables when they start. They “chop” it up as they go. And what they “chop” can either be a delight or disaster. There are no guarantees until and unless the software developer learns, trains, drills, and submits to constant review for a very long time. As our industry matures, the information we must know increases; the time we must practice grows; the review becomes more critical and robust.

And staying senior, skilled, experienced, and trusted is, in itself, a full-time job. I don’t know why anyone does it.

Developing software is not for the management trainee.

Neither is deciphering the uninformative titles littering the technical landscape. (Yes, we’re still talking about titles.)

Our industry, unfortunately, cannot decide what to call us. There are 27,119 names for software developer/programmer/coder. We’re software specialists, Dev I through XX, Programmer 1 through 27, analyst this or customizer that. There’s no way to tell what we do by the title.

And isn’t what this rant is all about? Of what use are titles when we have to append every title with 27 8×10 color photographs with circles and arrows and a paragraph on the back of each one, telling what each one was to be used against us in a court of public opinion? Titles, themselves, condemn us to a 15-minute discussion, definition, and clarification that titles used to be used to avoid.

It’s not enough that we’re poorly defined, but the world seems to hold it against us that our own customers and employers can’t agree on a “Hi, My Name Is …..” nametag either. We bear the shame.

Regardless of the mundane title, the software developer bears all responsibility for:

• understanding the business model
• correctly interpreting business and technical requirements
• choosing and teaching the platform and tools selected for the application
• training, pairing, reviewing, assessing, and growing the knowledge base of every technical member
• maintaining internal and external communications and recording decisions for posterity
• solving the mismatch between business and technology
• delivering a superior technical product
• delivering a usable interface
• data maintenance and storage
• security
• authentication and integrity
• negotiating realistic budgets and schedules against unrealistic and ignorant demands
• requirements, documentation, specifications, reports to management, change management, testing requirements, etc. etc. etc.
• and the thousand other things that drop, like rain, onto the software developer’s lap every day

Didja notice that none of the demands on the DEV-IV, Tech-III, HAL-2000, or any of the other titles given us deal with actually writing the source code that turn hallucinations into applications?

If you’re very perceptive, you’ll notice that all but two or three of these “requirements” belong to the manager. We’ve established that managers are incapable of managing technical tasks so they hand all the managerial duties to the technical team already tasked with calling worlds into being with our logos, our words of power. In other words, managers have found a way to make our job our job but also to make the managers’ jobs our jobs, too. I wouldn’t mind it so much if we fired the managers and got their pay appended to ours. We don’t. We do their work. They get paid for our labor. We get told they’re the smartest people in the room.

If you’re playing along at home, you also notice that all of these demands must be accomplished in spite of the managerial ceremonies and oversight enforced to give the non-technical impediments some feeling of control. (Note to managers: the only control you have over the technical project is hiring and firing of the technical developers. While we’re recognizing that this is topsy-turvy, so long as the Taylorism of the 19th century remains, the best thing any manager may do to help is hire the most senior developers in the greatest numbers.

The single factor with the highest correlation with software development success is the number of senior, experienced, educated, and skilled software developer leaders. Other things may matter, but nothing else matters as much.

Techno-Scrabble without real words

We confuse the rest of the world with the titles we give our software developers, though. Apex Amalgamated says they’re looking for a Dev-IV. Sidestep, LLC Inc. says they have an opening for a Tech-III programmer. Someone with a crystal ball and a subscription to NSA’s eavesdropping tools would quickly discover that they’re the same job.

As the same time a Giggle Engineer-VI and a McArthur Doogie Data Scientist 3 aren’t even software developers; they’re managers placed to oversee technical experts and the other managers thought their titles had to imply they were technical, even if they weren’t.

Programmers are the same as Software Developers. Coders are the same as programmers. Some people define them in a hierarchy where one is paid better, respected more, or placed on the org chart above another. It’s meaningless!

If anyone is a software developer, programmer, coder, Dev-IV, Tech-III or anything else, the next question must always follow: “sure, that’s great; what do you do?” If a non-technical executive doesn’t already know what those titles do, they probably won’t be able to understand the answer. I hope they ask it anyway. It gives the software developer a chance to practice the “tell us a little about yourself” question waiting inevitably at their next interview.

People who impede application development

There seems to be greater label variety for those who accomplish less and impede software development more. The answer to this label-torrent is simple: they’ve done something that software developers have not grasped. They certify.

The more certifications, the better. The greater the number of letters in the certification acronym, the better. Managers end up with more extra letters appended to their name than an errant LLM with a gastrointestinal flu. They still don’t develop software (and may have a negative effect on those who do), but their suffixes compete with vice presidents for “word salad.” You can’t tell a book by its cover, but you might be able to tell an impediment by its title.

Here are my favorites.

Scrum Lord

Low-level peerage masquerading as Paladins of the Agile Court have generally agreed to descend from the Dutchy of Scrum. They refer to each other as “masters,” but no one can quite agree on what they’ve mastered.

Benighted by certifications, I suggest we bequeath the title “Lord” on them. It’s low enough to be largely recognized as “sobriquet” rather than charter. It confers a title which they can believe elevates them but all others recognize it sequesters them into isolation.

Scrum Lords carry the burden of totally corrupting the Manifesto for Agile Software Development. Even while shouting the battle cry of “Agile!” they create, proclaim, and promote an entirely different gospel, as the saints might say. I don’t need to specify the differences. Just read the Agile Manifesto and its 12 Principles and invert the meaning of each. Viola! You have Scrum.

The sports reference, though, is descriptive. Imagine a clutch of grossly antagonized players pushing and yelling until one person – through guile, force, deception, or infliction of overt pain – gains control over the central focus of the human press. What happens next is organized chaos until another scrum must be called.

This cannot be “agile.” This is manipulation, abuse, bullying, and downright rigid control.

Why, then, would anyone fall for it?

Taylorism. Pure and bold-faced Taylorism. It appeals to the manager. The manager is in charge. As it was in the beginning is now, and ever shall be, whirled without mend. The smartest people in the room are pawns. This fits the necessary narrative of the Modern Major General.

I’ll drop the url for a Wikipedia introduction here: Scientific management – Wikipedia

In brief, Taylorism had its day in industrial manufacturing and the belief that “top men” managed “strong backs” and that empiricism would guide the “scientific manager” into efficiencies the strong backs could not, on their own, produce. Does that sound familiar?

It was a practice eventually discredited even before Fredrick Taylor died, but innovative giants like Lennin and Leon Trotsky loved the ideas and championed them whenever they could. These should be sufficient advocates to gain a TL;DR understanding of what makes Taylorism appealing: the manager plans the lives of the proletariat, and it becomes the worker’s fault if things go wrong. It’s a management philosophy “Taylor Made” for a five-year-plan.

I don’t think I’ve ever so succinctly defined Scrum.

Warning: the presence of a Scrum Lord in any group guarantees a loathsome workaday experience.

Since this is about tiles, the following Scrum Certification titles are offered as identification of the species:

• Advanced Certified ScrumMaster (A-CSM)
• Certified Scrum Developer (CSD)
• Certified Scrum Performance Art Manager (CSPAM)
• Certified Scrum Master (CSM)
• Certified Scrum Product Owner (CSPO)
• Certified Scrum Professional (CSP)
• The Advanced Certified Scrum Product Owner (A-CSPO)
• Certified Scrum Professional Product Owner (CSP-PO)
• Certified Scrum Professional Scrum Master (CSP-SM)
• Disciplined Agile Scrum Master (DASM)
• PMI Agile Certified Practitioner (PMI-ACP)
• Professional Scrum Developer
• Professional Scrum Master (PSM)
• Professional Scrum Product Owner Level 1 (PSPO-1)
• SAFe Scrum Master (SSM)
• SAFe Advanced Scrum Master
• Scrum@Scale Practitioner

Admittedly, some of these dog tags don’t have acronyms, but they’ll make some up. When you ask what XYZ means, and they say, “Professional Scrum Developer,” rest assured this has nothing to do with writing code.

Project Manager

Project managers used to walk the catwalks over the factory floors, observing productivity via activity. Project managers do that today only with fewer opportunities to yell down from the rafters, “Hey, there! Pick that up and move it over there!”

Project managers still don’t know anything about the technology of the software development biniss. They only know management. The pinnacle of project management used to be the Harvard MBA.

It was a lie then. It’s a lie now. But here we are: Project Managers in name only without a catwalk to proclaim their superiority.

They do have their certifications and acronyms, though:

• Certified Associate in Project Management (CAPM)
• Project Management Professional (PMP)
• Certified Organizational Chart Flipper (COCF)
• Portfolio Management Professional (PfMP)
• Agile Certified Practitioner (ACP)
• CompTIA Project+ Certification
• Certified Assistant Junior Empiricist (CAJE)
• Junior Assistant Associate in Project Management (JAAPM)
• Associate in Project Management (APM)
• Professional in Project Management (PPM)
• Certified Project Director (CPD)
• Certified Project Management Practitioner (CPMP)
• Master Project Manager (MPM)
• Certified ScrumMaster
• PRINCE2 Certification
• Project Management in IT Security (PMITS)

Again, don’t be misled. “Agile Certified Practitioner” never once relies on the Manifesto For Agile Software Development. That might actually be useful. But it’s management, and therefore, the antithesis.

Product Manager

Follow along, if you can, the words taken directly from Wikipedia on Project Manager.

A product manager (PM) is a professional role that is responsible for the development of products for an organization, known as the practice of product management. Product managers own the product strategy behind a product (physical or digital), specify its functional requirements, and manage feature releases. Product managers coordinate work done by many other functions (like software engineers, data scientists, and product designers), and are ultimately responsible for product outcomes.

Now, play the game of Buzzword Bingo. You have to take a shot of tequila every time you read a buzzword. You have to take a bong hit every time you read a vague phrase. This game is rigged.

Worse yet, the title is defined using the title: A product manager manages the production of products. (This requires two bong hits and a shot of tequila. You get the worm.)

No wonder managers love this stuff.

• Own the product strategy (bong hit)
• Manage feature releases (bong hit)
• Coordinate work done (bong hit)
• Functional Requirements (shot)
• Software Engineer( shot)
• Data Scientist (shot)
• Product Outcomes (shot)

You wouldn’t survive the rest of the Wiki article. Only Jerry Garcia’s ghost could come out in the same condition he went in.

And, for the last time, a list of acronyms that certify the Project Manager:

• Professional Certified Marketer (PCM)
• Product Activity Professional (PAP)
• Lead Scrum Dance Master (LSDM)
• Certified Product Manager (CPM)
• Master Project Manager (MPM)
• Senior Master Project Manager (SMPM), with clusters
• Certified Manager Certification (CM)

Have you noticed how the certifications of the managers start to sound alike and use each other’s titles: scrum this, project that, certified everything.

It’s all in the titles, and the titles don’t mean a thing.

The Last Word

I think King Crimson may have the last word on words. It’s only talk.

Elephant Talk

King Crimson; Discipline

Talk, it's only talk
Arguments, agreements
Advice, answers
Articulate announcements
It's only talk

Talk, it's only talk
Babble, burble, banter
Bicker, bicker, bicker
Brouhaha, balderdash, ballyhoo
It's only talk
Back talk

Talk talk talk
It's only talk
Comments, cliches, commentary, controversy
Chatter, chit-chat, chit-chat, chit-chat
Conversation, contradiction, criticism
It's only talk
Cheap talk

Talk, talk, it's only talk
Debates, discussions
These are words with a D this time
Dialog, duologue, diatribe
Dissention, declamation
Double talk, double talk

Talk, talk, it's all talk
Too much talk
Small talk
Talk that trash
Expressions, editorials
Explanations, exclamations, exaggerations
It's all talk
Elephant talk
Elephant talk
Elephant talk

Thank you, Adrian Belew for a testament to the enduring English language. I wish we could do it a service as much as yours.

What If We Were Honest?

If we were really honest about what we do in the techno-software chaos-land, how would we structure a working and proper organization, and what duties would accompany each title?

There’s An Architect

That may be the first thing you notice. “What a hypocrite,” you say. You’d be right, except I want to use my own definition of Architect: someone whose obligations are first, to the user, second, to the function, and third, to the topology. In that order and with little more to consider as architect. That’s enough!

There Are No Managers

Next thing to notice on this org chart is the absence of managers. This is no trivial act. Technologists can run themselves.

If they choose to use Jira, so be it. (They won’t.) If they want representation in executive meetings, there are no representatives who play golf with the VP. The Software Architect is not the mouthpiece for the whole group. The Senior Software Architect is the source and arbiter of vision for the software.

The Lead Developers are only segregated because of their a) breadth of knowledge, b) domain experience, c) wisdom, d) their promise to bring donuts to every group gathering, e) I dunno. Someone has to make a decision when there are more than one voice. The Lead Developer makes those choices.

If they were special operators in deadly battles (and this is as good an analogy that fits), then the Lead Developer would be called “Cap” by the other developers. It’s not because of some certification. It’s because this person can be trusted to bring the mission home. Period.

The Chief Developer would be, similarly, called “Chief” by the other developers. Developers are a rancorous bunch. The Chief is the beat cop, the source of direction, and the one person who can do what is required if anyone becomes incapacitated by time, other duties, or simply need of the education.

Developers round out the bunch. That’s it. No titles. No hierarchy, really. The nameplates on each of these boxes could change on a whim and daily if the developers think it will help them and their software.

Only those inside this group can decide who fills what box, when, and for how long.  

There’s an ergonomist there, too. Anyone notice? That may be a consultant, contractor, cockpit designer between battle platforms… anyone who can advocate for the user and improve the user experience. (They’ll probably have worked at Apple.)

Who Manages?

I’m so glad you asked. I’ll reply. Who manages what?

• Who makes out the burndown charts?
• Who keeps the Gannt charts?
• Who cleans up Jira?
• Who keeps a backlog list?
• Who reports on the expected delivery dates?

Nobody, nobody, nobody, the whole group, and it’s a constant negotiation, innit?

Since the ideal world totally rejects the 19th century ideas of production through empiricism, our software developers can realize the Manifesto For Agile Software Development.

Oh, oh

It means a lot more conversations between a lot more people who haven’t been allowed to talk to each other until now. It means that any developer working on any aspect of any software can call the CEO for a five-minute discussion. It means the same for every developer and every other member of what might be considered “the Customer.”

It means that the managerial buzzwords like “definition of done” or “deadline” lose their meanings in the face of what actual software developers face and decide every day. It means that buzzwords get replaced with descriptions: real words with real meaning.

If a software demo must be shown at the Idaho Trout Show, then it becomes a negotiation of what actually can be shown by the time the trout to start biting in Idaho. It introduces the concept that demos are not real.

It means that anyone in the company can run the software as it stands today and see what it does and how it looks. This, too, becomes the tinder for wildfires of conversations.

Be ready for reality to uncover the historic instability that managerial lies have gaslit for decades.

Building the Group

Developers select developers. In software development, the single most important correlation with success comes from the numbers of experienced developers and the degree of experience of each. That means that when the Senior Software Architect wants to hire another developer, HR cannot mandate the kind or seniority of that developer.

It also means that the Lead Developer of every group has the obligation to increase the experience and skill of each developer (including the lead) every day. How that’s done is unstated. That it must be done is non-negotiable.

The Tower Comes Down

When any of this comes to fruition, and it will, I expect an earth-shattering boom! But only those walls built on the foundation of sand will fall. Strong walls of knowledge, respect, duty, integrity, and honesty will stand.

Those statements were enshrined in 2001. While I’ve considered letting the reader work to read it, I’ll place the entire Manifesto For Agile Software Development here.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Twelve Principles

Principles behind the Agile Manifesto

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Authors:

Manifesto for Agile Software Development (agilemanifesto.org)