For this Q&A, VMblog sat down with Mike Fitzmaurice, a renowned expert in low-code development and the VP of North America and Chief Evangelist at WEBCON. In this exclusive interview, we dive into the fascinating world of low-code, as Mike shares valuable insights based on the results of WEBCON's recent survey. Discover the latest trends, challenges, and success stories that are shaping the landscape of application development. As we explore the topic, Mike also sheds light on the impact of AI-generated coding. With advancements in artificial intelligence, are developers witnessing a paradigm shift in how applications are built? What is the potential of AI-driven solutions and what is their integration with low-code platforms look like? And how has this affected software bots and RPA?

Join us as we uncover answers to those questions and explore the transformative role they play in accelerating development processes while maintaining code quality. 

VMblog:  Your company recently did a survey that found 84% of CIOs expect the importance of low code to increase over the next 12-24 months, yet you've expressed a desire to stop talking about low code. Why? And what should we be talking about instead?

Mike Fitzmaurice:  Because low-code is almost everywhere and will be everywhere in a very short time. It's normal. It's almost the default. We don't talk about GUIs or drag-and-drop anymore.

As for what we should talk about instead, it's about what we're using low-code (or traditional code) platforms and tools to build. Business processes and data-driven decision-making are two topics I personally favor.

VMblog:  That same survey noted 70% of companies are shifting to citizen development, but only half of those that have tried up to now have reported success. What's failing?

Fitzmaurice:  The failure is in assuming that all you need to do to turn sales coordinators, graphic designers, administrative assistants, middle managers, etc., into developers is to hand them magic low-code tools. There's more to development than just coding, and there's more to solution delivery than just development.

The flaw in citizen development is asking citizens to bypass and/or supplant IT. They should be assisting and guiding IT.

VMblog:  According to your survey, more than 80% of CIOs report the need to increase the pace of development, yet more than half already struggle with the risks a large app library presents... what has to change?

Fitzmaurice:  They need to build more applications, but they're afraid that having more applications will result in an unmanageable mess. Those conclusions aren't in conflict. If a lot of applications are built independently in multiple places in multiple ways by multiple people, that fear is justified.

It requires a change in mindset, in which we think less of applications being individual-crafted works and more of applications being mass-produced by a factory. No two applications are completely alike, but why not apply a common user interface approach, a common security model, a common auditing and metrics framework, a common documentation requirement, a common training plan, and so on? Reinventing the wheel every time kills productivity.

Instead of focusing on one application at a time, focus on the total throughput of the organization. That can't happen without IT being at the center of things. And it also can't happen well without users and business leaders taking on a bigger role than "customer."

VMblog:  Which phases of application development and delivery do you think present the greatest risk or challenge for most companies?

Fitzmaurice:  Believe it or not, it's not the actual construction. Construction, coding, building... call it what you will, but it has gotten 99% of the attention in low-code land.

The biggest problem is in design, and by that, I'm including requirements gathering, specifications, acceptance criteria - all of that. It's still a largely manual process. It's still a largely adversarial process in which customers negotiate with vendors or IT departments. It's still usually a process where each side assumes the other side doesn't really know what they want, so they work hard to create de facto contracts to hold everyone to; ironically, everyone interprets the contract differently anyway, and we still see a client-developer disconnect.

The second-biggest problem is in deployment, and by that I mean everything needed to deliver a lasting solution beyond just constructing it. That means change management, documentation, maintenance, training, soliciting and curating feedback, security, and a lot more. Citizen developers don't even think about such things. Professional developers think about them, but hate doing them - so they don't get handled until the last possible moment.

VMblog:  How does low-code play into these other aspects of application delivery?

Fitzmaurice:  Low-code tools, well - different kinds of low-code tools -  could address design and deployment, but they're a rarity. Moreover, many organizational cultures are locked into a one-fixed-priced-project-with-a-clear-beginning-and-end mindset.

But what if you had design tools that created working examples of applications that were easy for non-technical users to work with? Tools that left out details but nailed the fundamentals. Tools that created starting points for developers that removed ambiguity so they could get to work right away finishing the job. Something that assisted with design with low-code development in mind.

Moreover, what if the platform itself offered every application a workable/robust security model that they could just use and move on? A documentation approach, an auditing facility, a metrics reporting system, a change management method, and so on. Don't use low-code tools - use complete low-code platforms.

Interestingly, the "high-code" or "full code" world has indeed spent a lot of thought and work on this, and the result is DevOps. LowCodeOps is popping up in a few platforms out there, and it's DevOps in spirit - albeit executed in a very different way, of course.

VMblog:  What did you learn through this survey about who was creating applications, and how has this information changed your viewpoint on how we need to look at approaching application building?

Fitzmaurice:  We felt that the biggest users of low-code were professional developers, not citizen developers, and the results showed that gut feeling to be on target. Much like we've seen a few well-received movies shot on iPhones, we can see excellent applications built with low-code tools. In both cases, it requires expertise on the part of the tool wielder.

The key is to embrace that. Get users and stakeholders involved in design. Foster communication between them to reduce ambiguity and see to it that requests are framed in ways that are actionable. Build using technology that handles deployment details at the platform level so each application doesn't have to address it.

VMblog:  With AI like ChatGPT being introduced as a cure-all, what are your views on how much of an impact AI-generated coding will have on building applications?

Fitzmaurice:  AI isn't new; it's been used by applications for a while now for making inferences and recognizing patterns, for example. What we've seen recently is a massive surge of interest in generative AI, where new code/text/images are created by extrapolating from massive volumes of scanned examples.

It'll help, but it's not magic. AI can't generate good new work without being able to scan huge volumes of past work. We'll need to analyze a lot of existing applications before an AI can generate something useful. More than any one company can produce. If we want to train an AI how to build business applications, many companies are going to need to share examples. I'm not sure they're willing to expose secrets to help a greater good.

There's the matter of "hallucinations;" you might have heard about an attorney that submitted an AI-generated brief that cited cases that didn't exist. That's likely to be a solvable problem if we can feed more and more data to an AI, but eternal vigilance is going to be needed for the foreseeable future.

More than that, though, is the fact that applications aren't deliverables - they're relationships. They evolve based on feedback, changing business conditions, etc. AI isn't at the point where it can explain why it generates what it does, how it works, and what should be done to ensure changes don't have unexpected consequences.

VMblog:  This time last year, everyone was talking about software bots and RPA. That's been overshadowed by AI, but when we weren't looking, did RPA become part of the low-code phenomenon you're talking about?

Fitzmaurice:  Sort of. Most of what you're describing stems from the zeitgeist's attention span having limits - but not all. I'm not ready to say (as I do for low-code) that RPA is so commonplace it's no longer special, though.

What I do think is going on is that organizations have had time to work with RPA more, and they've come to realize that it doesn't solve everything. It's an important piece of some solutions, but it ideally works with digital business process management, with application integration, and so on. And frankly, I think that's a very healthy development.

##