I love low-code. It can, and is, changing business solutions for the world. Due to a recent business model change we are stretching low-code to the limit, and occasionally finding that limit.

The New Model

I have written in the past about our new Unlimited Services Model we call The Works from Forceworks. This has been a tremendous success for both us and our subscribers. The key attraction seems to be the unlimited deployment, configuration, and customizations we offer for a fixed monthly cost. Everything except “Development Code”. Needless to say, our subscribers are expecting us to push the boundaries of low-code since that is on the all-you-can-eat buffet. And we are!

The Old Days

Before this new model, customers paid us for everything we did. It did not matter if it was no-code, low-code, or full-on development code. Our embracing low-code was more a reaction to customers preferring it. It is certainly easier for a customer to eventually take over, or switch partners, if their environment is not a minefield of code “black boxes”. Having a customer keep you on the team just because you are the only one who can figure things out is a timebomb waiting to blow up in everybody’s face.

Low Code

We jumped on low-code before the train even left the station, in very early MVP private previews and pilots. As a pure development company at the time it seemed like more of a novelty, something a customer might use instead spending the money to “do it the right way”. But that low-code train kept on chugging and getting more and more capable. In truth, low-code is the highest level of code there is. Behind the abstraction layer users see, is a massive amount of code to enable the “low-code” experience on the front-end.

Technical Limits

I continue to marvel at the things our team has built for customers using only low-code. Particularly knowing how much development code that would have taken only a few years ago. After all, this was the impetus for launching our new model in the first place! Can we actually solve every customers’ requirements without code? Unfortunately, not always, maybe someday.

Occasionally our low-code team will hit a “technical” wall on a requirement, something that is simply beyond low-code today. Our low-code team is disincentivized to bring in developers, so they will exhaust every low-code option before they tap out. But it happens. While Microsoft is continuing to push the low-code envelope, there are still some technical limitations for certain things. Things that low-code, which in the grand scheme of things is still an infant, cannot cover. Fortunately that list of things is continuously shrinking.

Practical Limits

Just because you can, doesn’t always mean you should. We have often spent hours solving a customer problem with low-code that could have been solved in minutes with code. That’s fine, low-code is all-you-can-eat in our model, and our low-code team is a lot less expensive than our developer team. As long as it is not a technical limitation, our team has been directed to continue the low-code course. Sometimes this results in a compromise solution and other times it results in a Rube Goldberg Machine.

“A Rube Goldberg machine, named after American cartoonist Rube Goldberg, is a chain reaction-type machine or contraption intentionally designed to perform a simple task in an indirect and (impractically) overly complicated way. Usually, these machines consist of a series of simple unrelated devices; the action of each triggers the initiation of the next, eventually resulting in achieving a stated goal.”

Many of our customers are perfectly fine with this as long as it does not cost them any more money, and I get that.

Development Appetite

I would say that we have about a 50/50 mix of customers today. Half that are good with however a problem can be solved with low-code off the buffet, and half that ask, “Is this the best possible way to solve this problem, buffet notwithstanding?”. We classify these latter customers as having a “Development Appetite”. That does not mean they want to throw unlimited funds at development, they still intend to maximize their subscription, but they see the value of not having any compromises or Rube Goldberg machines in their business application. It’s a choice they make.

I stand by my past statements that 90% of businesses will not require development code to accomplish their goals. And of the ones that will need code, 90% of what they want to accomplish can be done without code. So I guess this post is about the 10% of the 10%. But no one will be happier than me when Microsoft closes the gaps.

The Developers Challenge

Most developers I know are perfectionists. Code is tedious and not forgiving of mistakes. One out of place semi-colon and the whole system doesn’t work. To be a successful developer you have to be a perfectionist, so the job tends to attract perfectionist personalities. Low-code flies in the face of “perfection”. It is not possible to accomplish something complex with low-code without a few hijinks or inefficient extra steps. I also consider that a coveted skill BTW, “Professional Hijinker”. But to a developer that is “less than perfect”. And asking a developer to use low-code to solve a problem is like asking the Chef for ketchup for his steak. I have said before that I think Perfection is the enemy of Good. But you can’t argue that Perfection is… Perfect.