Low Code: Short Term vs. Long Term Value

I spent some time with a low-code app building platform this week. I built a demo app with it, and I was pretty impressed overall. It wasn’t as bad as I had feared.

I did have two superficial thoughts about it –

Consistency Has Value in the Long Term

While working with it, I would get a little frustrated because it would take me longer to do something. But the hidden value I saw is that there’s less chance to color outside the lines.

In this particular platform, there’s basically one way to do most things. You can’t really get… clever, with your code. The way things are implemented is pretty regimented, and while you can get to the destination you, the route is sometimes a little circuitous.

In the short term, this can be annoying. But in the longer term – especially with larger, distributed teams – this would be a huge value-add. One of the problems with code is understanding it after it’s been written. And there’s always a tendency to try to demonstrate your skill by optimizing and abstracting and otherwise trying to leave evidence that you’re The Smartest Guy in the Room™

Not being able to deviate from implementation and coding patterns is weirdly freeing. The platform becomes “bad cop” – meaning, you can say:

I would have used [insert ridiculously theoretical coding methodology here], but I couldn’t because the platform wouldn’t let me. Bummer.

This leaves you with really simple, clear, understandable program flow. People behind you can easily figure out what you were trying to do without you have to explain it.

In some sense, the code becomes self-documenting because it exists in relation to a much smaller set of possibilities and patterns. When someone after you is trying to figure out what you were doing, there’s a vastly reduced “menu” of things you might have been trying to do, so it becomes easier to make sense of it.

A Common Execution Environment Removes a Lot of Uncertainty

If you assume someone’s codebase, and can figure it out, there’s still a lot of uncertainty about how to run it. What language is it written in? What runtime does it need? What dependencies does it have? What weird quirks about the environment do I need to configure?

I think every developer has some horror story about “just trying to get it running.” You can spend hours just getting a dev environment running correctly for some code before you even start thinking about fixing or improving it.

The particular low-code platform I was working with has a built-in runtime. They have cloud and on-prem versions, but either way, you’re writing an app to fit into their architecture. To deploy, you click a button and it runs inside their containered environment.

Like the other point, this is freeing. The urge to do anything interesting or clever in the runtime environment is gone – you have no choice, because it’s only going to run in one environment, one way. You’re all working towards the same runtime.

Again, in the short time, this might feel limiting. But over the long time, I imagine this is hugely valuable. Theoretically, the code will always run. Ten years from now, you can pull it off the shelve, understand it easily, change it, then put it back on the shelf in the same spot.

Both this observations point to a common problem in software development –

Software doesn’t “happen” at one time. We often think only about writing code. We don’t think about maintaining it, evolving it, improving it, or sharing it. With few exceptions, code only has real value over time. Unless you’re writing something for a one-time project then throwing it away, you are going to have to revisit that code at some time.

This means you have to understand it, and you have to have a place to run it. When every possibility is open to you, those two things can suck up an absurd amount of time. Reducing options in the short-term can be annoying, but over the long-term, the value should be huge.

I got my car washed today. I hate it went you have to drive out through the dryers and there’s some big timer flashing at you, because you have to time it just right – you have to drive slow enough to use all the time, but sometimes you go too fast, and then you have to back up. I think about this way too much, and it probably doesn’t matter. My Jeep looks about the same no matter what I do.

But this particular car wash was on a track. I was getting pushed along. I got pushed out through the dryers and spit out the other side and then I drove off. I didn’t have to think about it. And again, my Jeep pretty much looked the same as it always does.

Sometimes it’s nice not waste effort on things that don’t matter much.