Low Code

Pegasystems CTO: No silver bullets, low-code software dos & don’ts

We’ve known low-code software shortcuts in one form or another for many years before the current revolution. Pegasystems CTO Don Schuerman reflects back on this technology’s current guise and helps to provide a few low-code dos and don’ts.

Two buttons on a yellow background, one is green for ‘dos’ and the other is red for ‘donts’

The software industry loves a new label. So-called DevOps practices unifying developer and operations teams existed in various forms long before the DevOps revolution of the last decade or so. Artificial Intelligence (AI)-based inference systems existed well before the current AI epiphany phenomenon.

Perhaps even more fundamentally, software engineers have been drawing curly cloud bubbles around groups of network instances long before the advent of cloud, hence the name, obviously.

A pertinent popularisation period

Similarly, in many ways, low-code software shortcuts and templates have been used by software developers for at least half a century as engineers worked out ways of encapsulating certain repeatable functions and building macro-style automations into their programming procedures.

Not to downplay the new era of low-code completely, there are clearly now dedicated platforms that offer speedier acceleration and automation functions that many of us may have ever dreamed of. But this is not plug-and-play technology so we need to think about how we apply it when, where and how.

Helping to navigate a selection of the core dos and don’ts of the low-code no-code (LC/NC) space, Don Schuerman offers his viewpoint is his role as CTO of Pegasystems,  a company known for its customer engagement data platform with specific low-code functionalities.

In the world of so-called digital transformation where low code promises application delivery and process improvements at pace without complex coding, where are the most pertinent application points for this topical remedy to repetitiveness?

A remedy for repetitiveness?

Schuerman asserts that even hard-core coders (i.e. ones that poo-poo low-code) will admit that much of software development can be repetitive and unnecessary. Huge amounts of time are spent on refining requirements, combing through data as a part of application testing, checking for security holes and simply making sure everything works and meets the specification.

“There is also the slog of having to merge your code with other code, sort out conflicts and so much else besides. We know that IT leaders will readily admit that they won’t be able to meet the increasing demands for business applications through traditional coding alone,” said Schuerman, providing perhaps some wider acceptance that this is a new software reality that we cannot ignore.

Low code tools can be invaluable, but it is important companies understand how to get the best out of them with dos and don’ts because low code alone is not a silver bullet. Let us start with what not to do.

Don’t be afraid of an ‘app factory’

“Tapping the enthusiasm for self-improvement in how systems are transformed should not mean a free-for-all on low code tinkering. The value of production-ready apps built from low code tools can be undermined by deficits in performance, reliability and security. To avoid this, organisations need to establish a governance process for how the business relies on low-code systems. This can be defined as an ‘app factory’ that applies guardrails to the work of the app makers or citizen developers,” explained Schuerman.

Although it might sound like a step back towards Victorian times, the development of an app factory in this sense is argued to formalise a good deal of the process guidelines needed to make low-code (and perhaps even more importantly no-code software created by businesspeople) solutions more suitable for mission-critical enterprise usage.

If a business is able to identify potential problems in terms of security, functionality, personal or financial data governance issues, compliance and user acceptance, then this is a factory with no risk of child labour or union strikes.

Schuerman argues that it also establishes the parameters for how any given low-code application progresses through development to production; it also provides a framework for integrating the low-code application with Continuous Integration & Continuous Deployment (CI/CD) processes and automated testing tools.

The Pegasystems team in particular advises that the success of an app factory approach hinges on the transparency of what the guardrails are and the openness of the technology leaders within it to help their app makers as their peers.

Don’t get buried in the UI

In all software application development, a one-brick-at-a-time logical build process is generally a sensible approach. Starting small and building in modular careful steps makes lots of sense, it’s often the best way to define, tackle and overcome business problems with newly created digital solutions.

“However, one of the biggest challenges with low-code systems is how they risk creating teams that are new to development getting bogged down in the trivial stuff. Presented with a blank page, users of low-code systems can get over-focused on smaller, user-interface issues. Yes, I am talking about how big and where to put the buttons! To avoid getting lost in the small things, teams need to focus on the business logic,” advises Schuerman.

The question the team should be asking here is (for example) what are the steps of the workflow you are implementing and what decisions need to be made at various steps? Let’s not overly worry about the size and shape of the user interface buttons at this point; this is the point when hard core developers, citizen-developers, low-code developers and all other low-code system stakeholders should be standing back and focusing on business logic.

Schuerman says that when a citizen developer building an app goes down the route of spending too long thinking about the user experience and User Interface (UI) element, they miss a crucial period when they should be modelling business logic. He explains that the risk here is the development of a clunky low-code application that only ends up tightly coupling the app experience with one UI.

“Frequently, in the real world, applications will need to be accessed from multiple different UIs – especially if they are capturing processes that may need to be used by an organisation's end customers. Ensuring that low-code apps function as reusable ‘services’, means the apps need to start with the business logic, i.e. the workflow, and then connect that back out to appropriate UIs,” said Schuerman.

Invest in team building

One perhaps popular misconception about low-code no-code tools is that it is programming for dummies. In reality, working with users across the Pegasystems customer base, the firm insists that the success of these types of projects stems from a team’s strength and ability to think about business processes and how to improve them.

“A business adopting these tools needs to spot strong candidates who have a real curiosity and outstanding level of domain knowledge; they will be natural problem solvers with a personal reason to see the organisation’s applications become easier to use and more productive,” said Schuerman.

Ultimately, where these technologies are implemented well, Schuerman suggests that professional developers may find themselves taking on new roles as ‘coaches’ for low-code and especially no-code development teams. This in itself may then require a new set of skills for developers. Schuerman says programmers may now need to learn a new set of soft skills (collaboration, teaching, mentoring) that haven’t traditionally been emphasised.

“The success of low coding lies in how well you can strike the best equilibrium between letting go and applying some light but clear and firm controls,” concluded Pegasystems Schuerman.

Solid spanners & software sockets

As with any toolset then, whether that tool be a physical real-world spanner or a virtually created software socket wrench, just dropping a toolbox in front of anyone is likely to result in a few cuts and bruises. With the ascendency of low-code no-code no upon us, we need to think about how sharp these new implements are, get some safety goggles, believe in the credo of business logic, and make sure we’re using them inside an appropriate factory environment.

If we can do all that, then we perhaps deserve to use low-code no-code and wear the new overalls that come with this job. Enough for now then, what time is tea break?