When you consider a sphere, it’s well understood in math and physics that surface area increases by the square of the radius while the volume increases by the cube. In other words, what’s inside expands faster than what you see on the surface by a considerable amount.
That’s a useful metaphor for what many businesses are bumping up against as they develop highly customized apps using some of the powerful platforms on the market today.
Back in the day, never mind which one, software development was both easier and harder than it is now. You had programming languages to learn and code in, and you built apps very close to the metal; there were few bits of middleware that kept you comfortably abstracted.
The code you wrote was compiled and it ran. If you were a good programmer, you might have left comments in the code so that later developers could understand how the system was intended to work if your all-too-brittle systems stopped working.
Application Development Today
Modern platform-based app dev stands all this on its head.
For starters, the code is generated, and the variable names are often created by what seems to be random number generators which can make things difficult to follow. But also, in the increasingly low-code/no-code environment, we’ve given up on commenting because, hey, the info you need is right there in the specs. More or less.
As it turns out, those environments can be simultaneously terse and verbose. They’re terse in the passive aggressive way that only the bare essential information is there, sort of like the instructions for assembling furniture these days. They’re verbose because every tiny bit that could steer the code generator is laboriously spelled out.
Experienced human programmers on the other hand would intuit many of the subtleties and that’s a good differentiator between artificial and human intelligence.
A few years ago, I did some research on DevOps, simply put, technology that helps manage the development process on the Salesforce platform. A curious finding that we didn’t really have an answer for went like this: Medium-sized companies as measured several ways such as by the complexity of their development environments did better with DevOps tools than larger companies.
This was more than puzzling because bigger companies’ bigger development efforts suggested a bigger sphere with greater volume. The rest of the metaphor is simply that the surface area of those spheres, i.e., the running apps, was greater in quantity in the larger implementations.
DevOps Plateau
So, netting this out, we saw a plateauing for DevOps implementations’ utility when we expected a straight line up and to the right — to infinity and beyond as Buzz Lightyear might have said.
I hadn’t thought much about this apparent disparity for a while. We had checked our survey data and determined it was solid and moved on. Then I had coffee with a friend who works at the startup Elements.cloud, and things began to make sense.
First, let’s caveat the heck out of this and I’ll remind you that I don’t write code anymore. I once used a chisel and I think the industry has moved on. I am also trying hard not to be a shill for a startup, so I’ll stick to the facts I think I know.
You need to manage the verbosity of platform-based software development and to do that you need a kind of inventory system to tell you how many and what kinds of things you have sitting in the platform.
These things probably weren’t invented the last time I looked at an error trap such as classes, triggers, flows, global actions and who knows what else. If you don’t have such a system, you can get hamstrung by the terseness of the generated code as you try to find the good stuff among all the debris of earlier incarnations.
This offers a clue about why bigger instances of platform development environments bog down. In a DevOps only world, the way I understand it, you still need to find what you’re looking for before you can apply good management.
My Two Bits
Okay, this might be wrong and it’s just my crude understanding. But if there’s a kernel of relevance here it suggests a couple of important points.
First, new niches make even more new niches possible. Platform made more and better apps possible for any business, but they also made the sphere too big, which challenged the value of the surface area, which opened a new area for tools that redress the problem.
Second, we might be watching the evolution of new jobs that require new skills — and that may be a good thing. In my career I watched the evolution from no database administrators to their proliferation, and now to autonomous databases that obviate the need for DBAs.
At this point, having DBA in your background might be good training for platform developers. Some people might do that, others might become analysts.
Loading ...
