On schedules and hammers

After Southwest was hit with a (literal) perfect storm that crippled its route network, some in the Salesforce community have been quick to suggest rebuilding the airline's core systems responsible for scheduling on top of Salesforce's platform.

Let me state it in unambiguous terms: that would be a colossal mistake.

Scheduling is a complex problem

Humanity has been using computers to solve optimization problems for the past 80 years or so. These problems are relatively easy to formulate: an objective function, a bunch of constraints and off we go to the races. The issue is that some constraints increase the complexity of the problem to a point in which, if we want to find the true, single optimal solution to a problem, we are not guaranteed that the process will end at a point in time in which the answer will still be practical, no matter how many resources we allocate to it. This category of problems are called "nondeterministic polynomial", or NP.

A fictional example from an excellent piece of literature. In The Hitchhiker's Guide to the Galaxy, hyperintelligent pandimensional beings build a supercomputer, named Deep Thought, to determine the answer to life, the universe and everything. After running for 7.5 million years, the computer declares the answer to be 42. Now, that was a heck of an NP problem!

Most basic scheduling problems have been demonstrated to be NP. These problems are defined in lab settings that have streamlined conditions. Reality, however, usually gets in the way and makes things more complicated interesting:

• Problems end up having more than one objective, and they often are at odds with each other — triple bottom line, anyone?
• Some "softer" constraints are hard to express or have not been captured — this is the optimization-equivalent of an implicit requirement or a latent user story in software development.
• Reality is just huge — a scenario with tens of airports, hundreds of aircraft units and thousands of employees would lead to a situation in which millions of variables would need to be computed.

Now, when the true best solution is out of reach, we often settle for what we call a heuristic, which is a fancy name for "we made up this process that, so far, has come up with good-enough solutions". Heuristics, however, are still computationally intensive.

With all this in mind, imagine running optimization processes in a system like Salesforce, with strict resource and time limits to ensure that all tenants behave in a way that does not compromise the sustainability of its multi-tenant premise. The idea of using Salesforce to solve optimization problems does not look that cool, does it?

A hammer looking for nails

In his excellent, highly recommended Salesforce Anti-Patterns, Lars Malmqvist talks about the "golden hammer" architectural smell:

The Golden Hammer solves any problems—that is the nature of the Golden Hammer. Once you have found the Golden Hammer, every problem you encounter is a fit. There is no evaluation of fitness for purpose because the Golden Hammer is obviously the right solution.

The tech industry, in general, is very prone to Golden Hammers. We are always looking for the next cool technology to solve our problems. Salesforce with its aggressive sales approach and Kool-Aid drinking community is perhaps even more prone to this anti-pattern than most platforms in the technology space.

Note that Golden Hammers are often technically excellent solutions within their own solution space, but they are stretched well beyond that space because of enthusiasm, hype and excitement.

Or, as the adage says, when the only tool you have is a hammer, every problem looks like a nail. I believe there was a movie where they did a similar shtick with Windex.

There are multiple reasons not to spray Salesforce on every single problem an organization faces, but today we can think about one of them. There are specialized systems that can take care of very specific business concerns: core systems in banking, ERPs in manufacturing, spreading systems in loan origination and, yes, industry-specific scheduling systems. Some of them can be used off-the-shelf, some of them will need a heavier degree of customization, and some of them will have to be completely built in-house — maybe on-premises, maybe in the cloud. Keeping these systems separate from Salesforce provides at few clear advantages:

• Building it in a separate, specialized system provides modularity and replaceability.
• An independent system lets the organization choose the toolkit that best matches the business needs, including compliance.
• Via integration, these systems can serve other parts of the organization's IT ecosystem, without concerns about limits.

Could ≠ should

Once during a Trailblazer Community Group meeting, I came across someone who admitted trying to build a videogame on top of the Salesforce platform. It reminded me of Doom, which has been for years at the center of the game developing community. People have played it on the color display of a printer, on a MacBook Pro touch bar, on a pregnancy test, or (only theoretically) on 16 billion crabs. In all these cases, the gaming experience is for sure, very different from what we are used to with consoles and gaming computers.

This is where technical architecture lives — in the gap between technical feasibility and its desirability, in the difference between could and should.