Confessions of a Low-Code Convert
I am a coder. I write code. I program in C++ recreationally. And at work, I love low-code platforms <cue record scratch>. I suppose you’re wondering how someone like me became a low-code enthusiast. Here’s my story…
I’ve been doing business application development for the past 27 years, building accounting systems and lots of other internal workflow and business apps. I’ve been through all the iterations you can think of: Microsoft Foundation Classes, Visual Basic, ASP, JSP, servlets. I was a Java programmer from the way-back, 1.0 days in the ‘90s. In other words, I’m exactly the kind of guy who’s likely to sigh heavily if the phrase “low code” is uttered.
I love low-code tools.
The “Java is the new COBOL” joke isn’t baseless. Achieving a business objective without breaking anything is becoming more and more difficult in Java. It’s just too overweight. Java EE, object-relational mapping frameworks, UI frameworks, dependency injection frameworks to manage all the other frameworks — no matter what libraries and frameworks have emerged to manage that crushing complexity, we still find ourselves in a very tedious and time-intensive process of mapping and configuring and basically doing hundreds of lines of XML just to get to the business app equivalent of “Hello, World!”
As a business app developer, I started branching out, looking at more lightweight frameworks like Python, Node, the AWS space — what could I host there instead of relying on internal systems? But even those are well on the road to becoming just as complex and cumbersome as Java, and then you find yourself still having to manage selecting and wiring together all the disparate libraries needed to build your app. It’s better than Java, but only incrementally so.
When I started using ServiceNow, I was an app development manager, with six developers supporting 54 applications. The non-Java ones were a mishmash of mission-critical Excel, Access, Fox Pro, VB “classic” and PowerBuilder and every other thing you can think of (we even had a JCL script to pull accounting codes that we had to maintain), that had accumulated over years of the IT shop trying to find the silver bullet to accelerate app development. And we never had the bandwidth to replace or update them with Java or any other modern tools, so we were always in Band-Aid mode and barely maintaining everything. We simply weren’t agile enough, and the technical debt kept piling on.
One day, I had a customer who booked an hour-long meeting with me to talk about a public permit inquiry process he was running out of a shared Outlook inbox. He wanted to piggyback it on top of our IT service management installation. Within a couple of minutes, it was blazingly obvious that this was a terrible idea, but what he needed was a slam-dunk fit for a ServiceNow app.
I pulled up the development environment right there in the meeting room and started building the app as we were talking. We ended the meeting at the 37-minute mark because I was building the application faster than he could think about what he wanted for a future state. He left with a minimum viable product (MVP) he could show his team, and I left with the same endorphin rush that usually comes from writing a clever chunk of code to solve a tricky problem.
This wasn’t the first app I had built on ServiceNow, but it was my lightbulb moment on how powerful low-code tools could be. With traditional tools, that could have been a six-month process — and I would have had to tell him that unless it were a break-fix on a core system, I couldn’t help him anyway.
It’s much easier to fix or refactor an app written by a low-code citizen developer in the line of business than it is to decipher whatever madness they’ve slapped together in their massive, mission-critical Excel spreadsheet. I find low-code platforms incredibly sanity-saving. They reduce noise in the system and obviate a lot of the admittedly unexciting elements of my work.
The technology landscape has changed dramatically. Cloud adoption has introduced a world of serverless containerization. According to Gartner, the topmost currently used application platform is the Java EE application server platform, 40% of which are planned for replacement by July 2022. Those replacements are going to boil down to cloud-based containerization or low code.
Containerization makes sense if you need extreme elasticity and scalability for something customer-facing — if you’re building the next Netflix, for example, or a shopping cart, or a multiplayer online game. Internal business systems generally don’t benefit from containerizing and don’t need the resource elasticity that cloud platforms like AWS provide. Automating a workflow is an ideal use case for low code. And as companies are seeing an ever-increasing demand for remote work flexibility, it’s becoming more and more important not to have to create high-code workflows from scratch. It’s time-consuming and expensive.
In the end, if you’re looking at this equation from the business side, you want to be using your high-value programmers for high-value tasks. If you’re the developer, you don’t want to be bogged down in perfunctory, repetitive items that keep you from the unique, expressive problem-solving you want to be doing. So I say let the business analysts futz with the field order on that form, because you’ve almost certainly got more interesting problems to solve.
It’s the best of both worlds: you don’t have to build a full-on Java app for simple data management, and while you’re not trying to use your low-code tool to do scientific computing, you can definitely use it to get processes out of spreadsheets and inboxes for efficient, easy management. Process automation is a very well-defined application pattern. Building that from scratch over and over for the same type of use case doesn’t make a lot of sense, and it gets boring fast. Low-code tools make it possible to automate business workflow apps incredibly quickly.
Low code doesn’t mean “no code,” and the distinction matters. There are a lot of no-code tools out there, and they’re OK at first until you hit that “can’t get there from here” wall because the problem you’re trying to solve is just a little outside their intended use case. When you do, there is no migration path; you either replace them with something else and re-implement everything that’s not documented or well-designed to begin with — or you have to just try to keep it running as best you can.
Pro developers can be more productive using low code. They can even branch into areas they’re not comfortable building on their own. For example, if you’re building business apps in Java, you typically don’t do mobile app development as well, which results in a cumbersome process to create and maintain mobile UIs or worse, coordinate with another team building the native mobile interface.
ServiceNow’s native mobile capabilities make it easy to add mobile elements to business apps, with lower overhead and less complicated maintenance. And if they have a huge backlog, and they just don’t have enough time to build everything from scratch, why wouldn’t they gently offer some of those extra-mundane tasks back to the business analysts? Low-code is great for that.
Seriously though, I still write a fair amount of code — unsurprisingly, mostly data integration work between systems. It’s just I haven’t done any of the boilerplate crap that I had to do in Java. And that’s how I learned to stop worrying and love low code. If you’re looking for ways to ditch the mundane and focus on the fun stuff, you might want to give it a try.