Reading Time: 7 minutes

I usually write about front-end things or CMS things or node.js things. Sometimes a little of all three.

This is about all of those things at once. And it’s about how I think that, sometimes, enterprises are fucking dumb.

Note: The views expressed in here are not those of my employer. They are the views of thousands of people just like me.

Warning: This article is filled with profanity. Lots of it.

Some Background, before we begin

I don’t have a degree in computer science. Nor am I a formally educated engineer. I stumbled into this profession 12-13 years ago as a content producer; I was collecting and publishing content in a CMS. That evolved into being a business analyst, a technical consultant, a front-end developer, an architect, and a consultant.

I have done “agency work” for 10 years, now. I’ve worked with brands that are globally known, in a variety of industries like insurance, healthcare, retail, banking, investing, and manufacturing.

I am but a wee lad compared to some of my peers who’ve done this kind of thing since the advent of the web. But, suffice to say, I’ve been around.

Everyone Thinks they’re Special

Everyone thinks they’ve got a unique problem that no one else has. Maybe it’s the volume of content. Or maybe it’s the technical architecture. Or the business rules. Or the number of website visitors. Or users.

Ten years ago, if someone said, “we’re publishing 40k pages out of our CMS, you don’t understand how much of a challenge this is,” I would’ve thought, “Ok. yeah. This will be a challenge.”

Today, if someone says, “we publish a million unique pieces of content,” I don’t even balk at the number. All I think is, “so no one is in charge of your content strategy.”

When I hear, “we have a lot of complex business rules,” what I think is, “a lot of stupid shit lives in someone’s head and they’re afraid to tell anyone because that’s their job security.”

You’re not special because of how much content you have. Someone else has a bigger content problem. Ever heard of Amazon?

You’re not special because of your business rules. I mean, FFS, have you bought a plane ticket on the web? Like…ever? Those are some complex business rules.

Shut the hell up Karen about how hard it is to select the right energy drink.

Someone else has your problem. You are not special.

Everyone Favors Fixes over Solutions

I’ve written before about the difference between a fix and a solution, and I’ll summarize it quickly here.

A fix is removing an error or a fault from something. A solution is the act of solving a problem.

Fundamentally, a solution requires getting at the core thing that’s a problem, and eliminating it.

That means that if you are publishing to a file system, and then another app reads the file system, serializes and compiles data into content, and drops that content into a NoSQL database on a cron schedule so that a REST API can consume schema-less content and deliver it to a SPA, and you’re telling me publishing is slow (because it runs on an hourly schedule), a “fix” would be “find a way to manually trigger a re-scan of the file system”. A solution would be, “Publish directly to a damned database so you get on-demand content”

But why would someone want a fix when it’s obvious that the better approach is to eliminate three or four applications that sit between CMS and end-user?

Because a fix involves adding something to the existing system. A solution involves deleting most of it and starting over. Deleting stuff is scary.

It means you have to admit that mistakes were made (and that maybe you made them).

It means that you have to throw away all that hard work and admit it was technical debt.

It means you have to accept a a potential “unknown cost” of doing it right.

That’s why clients never want to actually solve their problems. They want quick and easy fixes that keeps their pile of technical debt under control.

Everyone Thinks <Software> will Fix Everything

You know what Slack did that Skype didn’t? It added cocaine glitter to every innocuous conversation you ever needed to have. Is it really better now that you have to read someone’s bullet points and figure out what the hell that dancing parrot means when they give their status update?

It doesn’t change the interruptions at all. It doesn’t change that it’s yet another knowledge repository I have to clumsily search through. It doesn’t change the fact that there are chats I should be in, but don’t get invited to, or that there are chats I am in but cannot find a shit in an Alabama outhouse to give for what is being said.

Slack doesn’t make people better communicators. (The fact that there’s countless “Slack Guides” is proof-positive) ¹. Slack doesn’t make you better at knowing who belongs in what discussion. Slack doesn’t make it easier to get projects done.

No software is a fix-all for a business

Adding Software does not Remove Business Problems

You could buy the fanciest chat client, the sexiest git repository, the most robust cloud license, the shiniest project management software, and whatever-the-hell-you-call-that-shit-Atlassian-sells.

It will not solve your problems.

You do not need another ticket-tracking software. If one is hard to use, either train your users or get rid of it.

You don’t need a third knowledge-base. In the name of Saint Fuck, if they aren’t using Confluence or IBM’s Knowledge Center, they aren’t going to use SharePoint. You need to find out why the hell no one will write anything down. If they say it takes too long, that’s not the software’s fault. It might have to do with the fact that Slack is a damned memory drain and someone is pinging them every 90 seconds asking if they checked their email.

A fourth CMS? No. Just No. You didn’t even need the other two. You need to put on big-kid pants and tell a few stakeholders, “no,” and learn how to use one CMS properly. Or ditch the CMS and start over. Someone in DevOps has been going to Krav Maga classes to blow off steam and she’s probably going to throat-punch your project manager if you tell her she has to setup three more environments.

Everyone Let’s their Front-end Team drive the Technical Architecture Reactively

I don’t mean “reactive” in that sexy React way. I mean “reactive” in the, “oh, shit. So you need JSON, huh?” kind a way.

I have seen an enterprise client that is a household name watch their ENTIRE SITE get rebuilt every.damned.time a page was published because they built the front-end in Gatsby, which is “static React”.

React, a JavaScript framework used to serve a web application to 1/7th of the world’s population, does not need to be used to generate a 200-page brochureware website. Your front-end team likes three things:

• Sentences that start with “bro”
• Hating on PHP
• Doing everything in JavaScript

This is not a team that should drive your application architecture. Somewhere in the world right now is a Fortune 500 company thinking they need Micro front-end component frameworks hosted in Lambda because Todd read a Medium article about how “On-demand Scoped SCSS is the future.”

Todd spent all of last weekend visiting microbreweries. He thinks “SQL” is is is an IPA”. Do not listen to Todd.

Do not JavaScript All the Things® because the front-end team says to. The front-end team doesn’t know how content management systems work ². They don’t know that content can change. They think in terms of YAML and JSON; they should never be allowed to dictate how data is stored or delivered, beyond what data is given back. The front-end team has an addiction to energy drinks and new shit. Do not listen to them.

The Front-end team will make fun of relational databases and data models and then use TypeScript with Angular.

And trust me. I’m a front-end developer.

Everyone thinks NoSQL will Fix their Shit

Data is relational. Almost all the time. It is rarely not relational.

When someone says, “we should put this in MongoDB,” what they’re really saying is, “we want this formatted in JSON.”

I have not worked with a single organization that has looked back on an implementation involving a NoSQL database that has said, “You know what. This was a good idea. We don’t regret this. Todd was right.”

I have, in fact, worked with many organizations that have said, “Todd was a fucking idiot. We’ve built a shit-ton of stuff to deal with the fact that content isn’t relational and it’s a nightmare.” I am not the only one who thinks Todd was stupid, either.

You don’t want NoSQL. You want your shit in JSON. Or maybe SQL + GraphQL. Or PostgreSQL.

Stop with the bandwagonning. Every time someone says “NoSQL” a kitten dies. Every time a C-Level says it an unknown species of whale turns to cocaine.

Oh, and in case you were wondering… you can replace NoSQL with “Containers, Docker, Kubernetes, or Cloud” for all I care. Your 15-page static website doesn’t need to be containerized, Todd. Who the hell even decided “container” needed be verbified?

In conclusion

Enterprise software is a lot like the entire 9-season character arc of everyone in Seinfeld: No lessons learned. Ever.

I see the same mistakes made at every enterprise.

• We are special and no one else has ever had this problem
• Bandaids are better than cauterizing wounds
• <Software> is a magic potion that will cure all of our problems
• Let’s add one more thing, what’s the worst that could happen
• The front-end team says we need to deliver content in YAML, so we should probably do that
• NoSQL/ Docker/ Containerize / Blockchain

But, Frank, what if an organization does change

It’s easier to start a new company that tries to do things “right” than it is to convince an existing company to stop doing things wrong.

If it were so easy to change people’s minds, the United States wouldn’t have 30,000+ Christian denominations.