Media Query Source: Part 38 - InformationWeek (US digital magazine); Low code: satisfying meal or junk food?

• InformationWeek (US digital magazine)
• Low code development platforms
• Short-term benefits for the non-technical
• Application lifespan often underestimated

My responses ended up being included in an article at InformationWeek (May 10, 2022). Extent of verbatim quote highlighted in orange, paraphrased quote highlighted in gray. Above image from cited article.

The query responses I provided to a media outlet on March 29, 2022:

Media: The good and the bad about low code.

Media: Looking for experts to explain the good, bad and the ugly about anything related to using low code development platforms. Let's make this article real-world, folks!

Gfesser: As a rule of thumb, firms likely can realistically expect some of the better low code development platforms to get them 80% of the way in terms of what they're looking to do, but it's the remaining 20% where the challenges reside. In other words, while it might be accurate to say that much of what a firm is looking to build in the near-term will be enabled by one of the better platforms, it's also likely that considerably less than 100% of mid- to long-term needs will be enabled.

From my experience, custom code will need to be eventually developed due to a variety of factors, such as unsupported features, unhandled edge cases, limited integration or limited scaling. Several years ago, for example, a health insurer CIO who had initially brought me on board as an enterprise architect for a digital transformation effort (the chief architect of whom later requested that I take over a portion of this effort following the director of architecture's departure), was sold on implementing one of the most popular low-code development platforms before the effort even started, and it didn't take long for issues to materialize.

Their presumption was that this particular platform would provide a significant jump-start with respect to building the user interface. And while this ended up being a generally accurate presumption, what wasn't taken into account was everything else that needed to be developed for the application. Quite simply, the chosen low-code development platform was built in a way which presumed use of its own components for services on which the user interface would depend. Yes, an effort to work with the low-code vendor ensued, but the jump-start didn't get the firm very far. 

In order to tackle that 20%, development teams needed to work with the platform vendor because everything was proprietary, not based on open source libraries or frameworks. Eventually, the platform was enabled to integrate with all of the custom microservices we were building, providing some needed flexibility and scaling, but there was a high dependence on the vendor in order to make this happen. What this means is that the vendor needed to modify their product, building their own code. While the development teams did not need to write this code, the vendor did, and the code was closed source. In effect, my client was funding the effort to build the vendor platform!

And it's very important to understand that it's not just what needs to be built that needs to be taken into consideration when adopting a low-code development platform. Typically, this type of product provides no version control (or version control only using a proprietary tool, kept separate from a firm's centralized version control) providing the ability to understand how instructions for a given solution have changed over time. And skillsets for such platforms aren't transferable. I've seen what initially seem to be some clever scripting languages, but apart from the incompleteness these often provide is the available talent base. Why would a strong developer want to pick up hard skills that they would never be able to use again? 

Don't get me wrong. Low-code development platforms can provide some short-term benefits, perhaps for non-technical individuals to build solutions due to a lack of developers (after all, there is a derth of talent). And perhaps these might suffice for some internally facing needs. But when it comes time to build externally facing applications for competitive advantage, low-code development platforms largely fall short. At a minimum, firms need to recognize what they're likely getting into when looking to adopt such a platform so that they can also actively plan for the long-term. As it turns out, most applications simply have a longer lifespan than initially expected.