Stop Writing Articles That Tell Engineers to Stop Doing Something

Software design and architecture is about trade-offs, not absolutes

Peruse lists of Medium engineering articles, and you’ll come across a number whose titles are telling us to stop doing something. “Stop Doing This…” or “Stop Doing That…”, they insist. I’m not entirely innocent. Going over my own writing history, it seems I’m guilty of having penned one or two myself.

In fact, in that latter example (Stop Capitalizing Acronyms in Your Class Names) one commenter rightfully called me out for participating in this practice, and suggested that I stop. I mused in response that that could make for an interesting self-referential article.

Software design and architecture cannot be absolutist

Fast forward half a year later, and I’ve finally decided to write that (hopefully interesting) article. My impetus, not surprisingly, was having recently come across yet another example, this one titled Stop using Integer ID’s in your Database.

The article made some good points about unforeseen problems that database-generated integer IDs can cause. I’ve personally encountered all of the problems mentioned in the article, and myself try to eschew letting my database generate my entities’ IDs as of late. As with most such articles, however, those points did not add up to a massive need for us all to STOP DOING IT. Such a notion is simply absolutist: “Here are some problems that could occur with X, therefore NEVER DO X!”

I perused the many comments that had been left, and was not surprised to see a similar — but opposite — absolutist tone emanating from the responses. “Those aren’t important/likely/reasonable problems,” they effectively, collectively, and heavily-paraphrasedly said, “therefore you should shut up and we should all continue using Integer IDs”.

Just stop it.

I’ll admit that I can take a strong position on how to properly design software, and architect systems. But the reality is, software design and architecture is a constant series of tradeoffs. Absolute statements do not belong.

I might argue (in fact, I often do) that microservices should be architected so that domain-oriented teams can synchronously collect and read their data in real-time, and then publish changes to this data for other domains to eventually pick up and use as they see fit. But you might rightfully turn around and tell me that, while that sounds great in theory, your organization can’t achieve that, for any number of reasons:

• It would incur costs that exceed the org’s budget
• Eventual consistency across domains won’t work with the org’s use cases
• The org is unable to hire the right people to make this model work

And so while I might be tempted to admonish engineers to Stop Making Synchronous Calls Across Domain Boundaries, the reality is that such a practice is sometimes necessary in order to meet our real-world financial/consistency/hiring situation.

Click-bait

Articles with “Stop Doing X…” titles are also viewed as clickbait. Invariably, you will be offending some number of engineers — particularly those who do X — right off the bat. Sure, your article might gain more clicks if it’s named thusly, but many of those clicks will be from readers poised to argue back. And your article will probably also gain more comments… albeit mostly angry, argumentative ones.

And maybe that’s your goal. But if your goal instead is to get your point across, to generate constructive conversation, and perhaps to actually change a few minds, then avoiding a clickbaity title is the first step.

What’s the alternative?

Should we never, then, write articles suggesting that engineers rethink their reliance on certain common practices? Of course not. But that should be the point of the articles — challenging a commonly-accepted practice — rather than demanding that everyone cease performing it altogether.

In fact, you’ll find that the true point of many of these articles — if you actually read through them — is to do just that. For example, letting your database auto-generate numeric IDs for your entities is a common pattern, but it can indeed cause negative consequences. And certainly, many engineers have never even considered these potential consequences, and are unaware that alternatives exist. However, it can still be perfectly reasonable for an engineer—after consider the consequences and alternatives—to determine that it’s best for them to continue with the database-generated IDs.

Likewise, I might point out the legibility issues that come with multiple consecutive capitalized letters (NSHTTPURLResponse versus NsHttpUrlResponse, for example). But others might rightfully decide that adhering to a pre-existing style guide or naming convention is the more important concern.

With that, I contend that one simple change would go along way towards avoiding absolutist attitudes all around:

Replace “Stop” with “Consider Not” in all of these articles’ titles.

For example,

Stop using Integer IDs in your Database

would become

Consider not using Integer IDs in your Database

My own

Stop Capitalizing Acronyms in Your Class Names

would become

Consider Not Capitalizing Acronyms in Your Class Names

or perhaps something a bit more snappy, such as Do We Really Need to Capitalize Acronyms in Our Class Names?

That simple change would switch the tone of the article from an absolute statement to the presentation of a potentially new point of view. In turn, practitioners of the pattern in question will likely feel less personally attacked from the outset.

Beyond that, it’s important to recognize that however strongly you feel about the downsides of doing X, there are almost certainly some reasons to continue doing it. You’d be doing yourself and your readers a disservice by not examining and considering those reasons yourself.

So, is this article too absolutist?

Earlier, I’d described this article as being self-referential. After all, it is telling folks to stop telling other folks to stop doing things. The irony was intended. But in seriousness, is this article itself too absolutist? Is there no valid X for which we should insist that engineers stop doing X?

There could be (and probably are) engineering practices that are indirectly releasing tons and tons of carbon dioxide in the atmosphere. Maybe engineers are unknowingly supporting child slave labor in Vietnam. In cases like this, then yes, it probably is warranted to insist that engineers stop doing whatever X is. But I have — and it could be because I haven’t looked hard enough — yet to come across any such articles railing against such dire outcomes.

Summary

We encounter far too many absolutist attitudes in the world today. We don’t need them infiltrating our discussions about software. If you’re a writer who agrees, then stop (sorry, strongly consider not) writing articles that tell engineers to stop doing something.

Like this story? Want to read more? Just subscribe here to get my latest stories sent directly to your inbox.