Using Low-Code and No-Code Tools Effectively

Earlier this year, a panel discussion facilitated by ACT-IAC that featured current and former government employees discussed some of the challenges agencies face when delivering new digital services. The discussion was extremely valuable for anyone working in or with agencies as they design and deploy new technology solutions. 

The primary issue discussed by the panel was the growing use of what are referred to as low-code and no-code tools as a way to speed up the delivery of agency digital solutions. These tools enable the creation of software using graphical interfaces, drag and drop menus, and prebuilt components to reduce the need for custom software code to be written from scratch. They create the possibility of new software being created without the need for a dedicated team of coders – a tantalizing option for agencies facing resource constraints.

While it’s true these new tools can speed up the creation and deployment of digital solutions, there are some tradeoffs that agencies need to consider in order to use these tools most effectively.

“No code” Doesn’t Mean There’s No Code

While low-code and no-code tools can reduce the need to write custom software code, one of the great misconceptions of these tools is that they involve no code at all — that no-code applications can be “code free.”

Content management systems like WordPress and Drupal provide an interface for content creators to write and format new content. These interfaces don’t expose writers to the details of the software code under the hood that every website needs in order to run properly. As such, they make it easy for people who don’t write HTML, CSS, and JavaScript to create new web pages or even entire websites. But behind the scenes, these tools generate the necessary software code for new web pages. The people using them typically never see that underlying code, and may never need to.

Similarly, low-code and no-code solutions provide interfaces for users creating new software applications. The details of the underlying code needed to run these applications is usually hidden for the user, so that they can develop the solution they want without having to worry about the code underneath. 

But the terms low-code and no-code don’t necessarily mean less code is used. The software code behind these solutions is simply hidden from the person creating them. In fact, low-code solutions may actually generate more code than an application developed in a traditional way — it’s hard to know, because we usually can’t see the underlying code. 

This can have important implications for government agencies.

Going From “No Code” to “Know Code”

Understanding the state of the code behind low-code and no-code solutions is important:

• Complexity in the code behind these solutions may tie it more tightly to a specific vendor platform. Unlike custom developed software applications, low-code and no-code solutions are usually not portable. If you want or need to change vendors at some point, you will likely hit some roadblocks.
• More complex code is generally harder to secure. While it can be comforting to not be exposed to the code behind software solutions, understanding the size and breadth of this code may be important for security reasons. Recent high profile examples of new vulnerabilities underscore the need for agencies to have an understanding of what’s in the code for their applications.
• Some aspects of software development still require specialized expertise, particularly if this software is being used by customers outside the agency. Ensuring that agencies are meeting customer experience objectives can’t be achieved solely by acquiring a tool that enables non-coders to drag and drop elements of a user interface onto a canvas and then click a button to push it out to users. 

While low-code and no-code tools can provide benefits, agencies should be judicious in how they use them and understand the limitations of what they can provide.

Mark Headd is a Government Technology SME at Ad Hoc. He is the former Chief Data Officer for Philadelphia, serving as one of the first municipal chief data officers in the United States. He holds a Master’s Degree in Public Administration from the Maxwell School at Syracuse University, and is a former adjunct instructor at the University of Delaware’s Institute for Public Administration. He spent 6 years with the General Service Administration’s Technology Transformation Services (TTS), serving on the leadership team for 18F and leading customer success efforts for TTS’ cloud platform, which supports over 30 critical federal agency systems.

Photo by Clément Hélardot on Unsplash