One of the things that I admired about MIT’s introductory computer science class is that it focused on the structure of computer programs. (Did I mention I am a structuralist?) Students went on to learn about bubble sorts, recursion (my Waterloo) and other programming techniques. But first they learned to look at computer code and ascertain how a program worked. Understanding the how (and why) of a computer program is a valuable reminder when we look at the emergence of no-code development.

The Drive to Make Software Development Easier

Seemingly since the first lines of computer code were written, people have been trying to streamline and automate the software development process. High-level languages like (Alert! Showing-your-age reference dead ahead!) FORTRAN and COBOL allowed programmers to skip coding in Assembly language. Of course, today we have a new set of high-level languages (Alert! Hanging-with-the-Cool-Kids reference coming!) such as Python, Java, R, and the like. Think of this stage as high-code development.

As software languages took hold, people started developing function libraries to go with them. You do not need to write a print routine. Just call the routine from a software library. Easy peasy. People extended compilers so you could simulate the behavior of your software program while you were still writing it. Think of this stage as modular code development.

The trend toward open-source software democratized software development by making it easy for folks to contribute bits of software that others were free to use in their programs. There was (and still is) a need for governing all this software—worrying about version control, bug fixing, management and the like—which led (at least in part) to the emergence of folks like Red Hat and Git. Enter citizen-software development.

What is No-Code Development?

Which brings us to no-code development. Write code without knowing a lick of software! Show your Engineering major friends that your BA in Fine Arts was a smart move after all! (See: Artificial Intelligence.) Google, Amazon, Microsoft (and no doubt others) offer suites of tools to enable no-code software development. No-code development sounds like a great idea: let the people who know the business process best be the ones to automate it. Avoid the years-long backlog that the organization’s application development group is working.

What could go wrong?

Time for a story. I was managing a large development project. On the software side, we were replacing proprietary code with C++. I asked our lead software development manager about the benefits of moving to a commercially available software language. “We can make mistakes thirty percent faster,” she told me. I learned a lesson that day about knowing the limits to technology solutions.

IT Still Owns Governance (and Support)

As my friend Andrea Mondello points out in this Withum article, IT managers need to ensure that governance is in place for no-code development projects. Why? Because the citizen developers doing no-code software don’t know what they don’t know. Perhaps you have someone using Tableau or Power BI to develop a dashboard for a project. If their no-code development app works you can bet that they will share it with a colleague trying to solve a similar problem. (And you should be encouraging them to share it.) Before sharing the app, ask this question: is the app documented? Bonus question: is it written in a way that make it easy to extend to an adjacent problem?

If the answer to either question is “no,” then it is likely that the app is going to break. And when it does, who fixes it? The answer may be “IT.”

I know. I can hear you groaning, “not another thing to worry about!” Not to worry. You can make a great start by gathering some folks from across the organization and deciding some rules of the no-code development road.

• Which no-code development platform will we use?
• Who will be affected by the no-code app? Who will make sure the app does not break something currently in use?
• What are the minimum documentation requirements for the app?
• Where will the published app be stored, so people know they are working with the “production” version?
• What extensibility requirements must the app address?

Andrea’s Withum article has other great suggestions here.

Create a Win-Win Situation

A UN agency we work with adopted these kinds of no-code development governance guidelines. I thought it was a brilliant move. The CIO encouraged the kind of locally adapted app development that country offices wanted. But the guidelines made sure that apps met a minimum standard for supportability.

Do not ignore no-code development or try to make it disappear. Embrace it, but provide some guardrails.