Lessons Learned on a Low-Code Journey

The popularity of low-code/no-code tools are on the rise as organizations chase the promise of creating ‘citizen developers.’ The idea of using these tools to empower non-technical developers and/or to free development teams from writing code line by line is certainly compelling.

About a year ago, a friend reached out to ask if I would critically review a book he was writing about citizen development. At the time, the expression was new to me but after reading and reviewing the book, I was intrigued. It challenged me to embark on my own citizen developer discovery. I want to share several applicable lessons I learned along the way.

Intrigued: Citizen Developer Tools Versus Dev Teams

The curious part of me was trying to understand if these were tools that would remove the need for expensive development teams. The previous, well-intentioned attempts had fallen short of their promise—think Computer Aided Software Engineering (CASE) from the 1990s as an example.

Around this time, I discussed the topic with the CTO of a progressive client. His business users would not wait for technical resources when they needed apps to address persistent problems. He was quick to point out  that low-code was preferable to shadow IT. The architecture for these low-code/no-code tools meant database administration was in his team’s hands. He was supportive of business units building small tactical pieces of functionality with a clear business case, and he supported them where possible through training and allocating resources to their projects for data integrations and other functions.

The Challenge: Write an App

Encouraged, I decided to challenge myself over one weekend to see if I could write a commercial application. I had studied programming languages like Fortran and C in the 1980s, but I’d never worked as a developer and had never written commercial code.

Start of Day One

I selected a low-code tool at random. I would recommend, however, that a citizen developer engage the IT team rather than choosing at random, as most low-code/no-code tools have an underlying programming language. If your organization is a Java shop, for example, then it would make sense to pick a tool that has the same language—in this case, Java—at its source.

I purchased a six hour training course on YouTube for $20. This would prove to be a wise decision. Learning the tool I selected was not straightforward, but the training course allowed me to pause the tutorials, rewind and repeat to ensure I was understanding concepts and could follow along with the ‘how to.’

First task: write ‘Hello World.’ I recommend that citizen developers start here. If you can do this, then it’s more than likely you can build something more complicated.

Three hours later (of which two were a system error) … it was done.

Clicking on the green button produced the screen below.

At this point, I still had more questions than answers. The GUI for the development tool was point-and-click within a Windows directory structure. There was no command line editor. I was even more encouraged. Could it be this straightforward?

A note: while it took less than an hour to complete the ‘Hello World’ task, I encountered a Windows system error which pointed to a server port error. The vendor’s help desk didn’t operate over the weekend, but their documentation was adequate; it took a further two hours of effort to fix the problem, which arose because my Windows Surface Pro was both a client and a server.

Would an ‘average’ citizen developer have been able to overcome this problem? I’m not sure. I recommend when trying low-code/no-code tools that you also trial the help desk, even if you need to pay for it. While many software tool companies try to force software engineers to work through wikis to solve problems, citizen developers may need more hand-holding.

The next step was to build an application. Most non-technical people tend to describe applications from a graphical perspective and as business functions. This is very much in keeping with how I worked for a further two hours, at which point the ‘Home’ web page looked like this:

Using data from our in-house spreadsheets, I created the data model below with relative ease. I believe a citizen developer would benefit from asking an in-house database expert to review this ‘design’ to save time later when maintaining the application.

This work was undertaken at the same time as I was building a second tier of pages to amend data. So, for example, the automatically generated customer page which allows a user to search, add, edit and delete customer records looked like this:

This was completed in four hours. Once the table was created with the correct columns, the creation of the web pages was automatic. In fact, it became repetitive and I found it was easy to lose my concentration and make errors.

I was learning to save every small change to ensure that the live web and mobile application builds were working. A professional developer would see this as a form of continuous integration for the citizen developer.

I don’t recommend having teams of citizen developers working together, at least at the outset, as it introduces branching and versioning and the concept of ‘breaking a build.’ Professional developers would need to be consulted at this juncture.

End of Day One

I had a real sense of achievement at the end of day one and was eagerly anticipating day two. Citizen developers should note that, at this point, I had produced what developers would call a prototype. It would be possible, upon reaching this point, to approach IT to assign a developer to finish the job. If IT does not have capacity, then keep going.

Start of Day Two

Having designed screens and a database, the next task was to add business logic.

Creating flows of work with rules was a more engaging task, but still accomplished via drag-and-drop or point-and-click. Boolean logic operators like if- then- else allowed me to quickly build logic and attach it to visual elements on the webpage.

This is an event registration flow where data is accepted from a web page and, based on a true or false response, treated differently depending on that response.

As before, the first workflow took some time to learn. There were many ways to both trigger an action and direct the subsequent work. After a further half day, I had produced enough working code that I felt I probably couldn’t learn a whole lot more and the application was roadworthy.

From there, creating the mobile version of the app was as simple as pushing a button. At the outset, I had set a switch for mobile deployment. The web and mobile editions were always in sync, and the GUI was adjusting automagically for the deployment platform. Citizen developers should check on in-house standards for web and mobile app deployment configurations and ensure their selected tool supports them.

End Day Two

Lessons from My Discovery

Organizations that want to adopt low-code or no-code tools will need to ensure IT support and training for business users that want to self-service their app dev needs. I recommend early engagement and frequent retrospectives with IT colleagues.

Business functions should consider ‘easy’ and tactical opportunities for piloting.

Allocate an uninterrupted period of time to focus on the task. Learning a new tool over a weekend was a really good idea, too. There was zero context switching, apart from my wife dropping in with coffee for a chat.

I recommend citizen developers try to be a little bit Agile for these engagements. Using a ‘Plan, Do, Check, Act’ methodology means that you are not ‘all in’ on this—you are simply taking small discrete steps to see if you can solve problems more efficiently than you would if you instead waited for IT.

Professional developers should ensure that any low-code/no-code tools produce code that can be imported into their standard IDE and that the citizen developer’s code is not locked into the tool.

As a DevOps Institute Ambassador, O’Reilly helps empower DevOps Institute community members with the SKIL framework to advance the Humans of DevOps with skills, knowledge, ideas and learning. Learn more about O’Reilly’s work in DevOps here.