The Seven Deadly Sins of Enterprise Software: Bleeding-Edgeism (#1)

This is one of a seven-part series: "The Seven Deadly Sins of Enterprise Software" which was originally presented at SDL Connect in November of 2019.

There are many sins of software, but not all of them are deadly. Only a handful of mistakes in enterprise software will have long-term ramifications for how your business operates.

One of those "deadly sins" is Bleeding-Edgeism.

The Origins of Bleeding Edgeism

Bleeding-Edgeism is a play on the term "Cutting Edge" —a term that we've used since the 19th century to describe something that delivers a decisive advantage or is positioned at the forefront.

Why we started using it is a mystery, but my guess is that door-to-door knife sales were competitive back in the day.

So from "cutting edge" describing an advantage, we derive the term "bleeding edge" to describe a risky advantage — an advantage where you risk cutting yourself.

Bleeding Edgeism isn't a singular case where the risks outweighed the gain. That three-letter suffix, ism, is what we use to describe the practice of carrying out some action, devotion, and adherence to something.

So while bleeding-edge technology is risky and comes with the opportunity of getting hurt, Bleeding-Edgeism is the continuous pursuit of hazardous technologies.

To phrase it more simply:

Where the Edges are Sharpest

Every sector of software development wants to be innovative and "cutting edge" to an extent, but one area, more than any other, tends to be bleeding-edge:

Front-end Development

Front-end development invokes three languages (HTML, CSS, and JavaScript) to address a wide array of topics like Search Engine Optimization, Accessibility, User Experience, User Interactions, and Branding – that the web browser consumes and renders.

JavaScript updates every year, CSS every few months, and browsers every few weeks — and this is in addition to ever-changing search algorithms, user research, and branding trends.

Because front-end is cutting edge by nature, of course, it will favor bleeding-edge choices that will beget Bleeding-Edgeism. Enterprises, particularly in the front-end domain, prefer risk over certainty.

Practical Examples of Bleeding-Edgeism

React at the Cutting Edge

In the front-end world, the most popular JavaScript framework by a significant margin is the React framework. React is a framework created by Facebook for building highly interactive web sites and web applications.

Facebook has over 1 billion users who expect an interface to load quickly and react responsively to their interactions. React solves this by offloading much of the job of rendering content in the web browser and doing so in a way that makes it depend on "state"; the idea that data can change rapidly from any number of "events" triggered by either user or server.

So React is an excellent solution to a Facebook-sized scale problem or a Facebook-complex interactivity problem.

When React Leads to Bleeding

React is not the right solution to a 15-page brochureware website. React is not the solution to building some simple interactive forms. And React is not the solution for generating a static version of a website managed with a Content Management System.

I have seen a case where an enterprise-level CMS (SDL Tridion) was publishing content for a Fortune 100 company, and that company's front-end agency chose to use React. So in pursuit of the bleeding edge, it was decided that the website should use React. Except, of course, the site wasn't Facebook. It was a product catalog with very little interactivity.

The client had chosen to use a particular React Framework called Gatsby.js — a framework used to build static websites with React. Static websites.

The client had neither Facebook's problem of scale nor level of complexity, and they chose a framework for using React in its least-useful manner.

The result was building new APIs so that the statically built site could consume content from the CMS. Not only that, but they also ran into an issue: publishing a single piece of content triggered a rebuild of the entire site. At the time, Gatsby wasn't able to rebuild individual pages.

Additionally, Tridion has complex link-resolution; one component on one page can link to a component on another. Link-resolution is a complex mechanism that lives on the publishing side of Tridion or within a .NET framework that SDL provides (DXA).

This client wasn't using Tridion's publishing to its full extent, and they were using React via Gatsby instead of DXA. They were using an API they'd built to publish non-web content to non-web places; this was an API custom build in node.js, and very cutting-edge in its own way.

So the intersection of a cutting-edge content publishing API and a cutting-edge JavaScript framework led to bleeding: The client ended up missing a critical feature of Tridion; component linking. Component linking, and therefore, link resolving didn't work in the architecture.

Course Correction

Remember that technology is the tool, not the solution.

We use tools to build solutions. Pursuing the tool for the sake of the tool is how we hurt ourselves. It's how we get cut.

If there's a new tool out there that promises to do new and amazing things, the first question to ask is, "what problem are we solving in our business by using this tool?" If you don't know what problem React, Vue, Angular, Ember, Preact, or FrameworkOfTheWeek.js solves, then you don't need to build an enterprise solution with it.

POC with a narrow problem

If you think some cutting-edge tool has potential, first single out your problem statement to a narrow scope such as, "We can't build logic-powered forms easily," or, "search needs filtering and sorting to help users find products."

Once you have a problem sorted out, build a proof-of-concept for it. Don't spend a lot of time on it, either! There's a great book called Sprint, which talks about a "5-day sprint" that Google has used with great success to quickly crank-out proofs-of-concept. The short sprint doesn't leave anyone with an expectation or obligation that things are perfect and have to be carried forward. The idea is that it's a quick discovery, a journey to the edge without cutting yourself.

It's vital that everyone put technology in its place: no matter how hemorrhaging-edge the tech may be, it's still just a tool —and tools that aren't part of a solution are part of the problem.