I’ve been hearing about the current trend in developing applications using a low code or no code approach. This is gaining a lot of attention from accountants as developing a usable application traditionally takes a great deal of effort and time. In the past, many accountants have turned to spreadsheets to knock out a quick and dirty app.
The low code/no code approach is somewhat different. Instead of traditional coding in a programming language such as C++ or Java, or using macros in a spreadsheet, the low code/no code systems use graphical programming to drop packaged processes into a workflow to create the app. It’s often billed as almost effortless.
I have to admit that I’m a bit on the fence with this approach. A lot of that hesitancy arises from my background. I started out way back when as a programmer, programmer analyst and DP manager before I went back to school for my accounting degree. Largely self-taught, I’ve programmed a fair number of business applications such as accounts payable and receivable, general ledger, and construction payroll, in almost a half-dozen computer languages. In fact, it was the desire to gain a better understanding of the processes in these and other applications that sent me back to school for an accounting degree. And I was a very early user of program generators such as Configurable Business System (CBS), which ran under the CP/M operating system and generated CBASIC code, and even “The Last One” on the Apple II (which really didn’t work).
In a number of respects, these early programming tools are similar in approach to many of today’s low code/no code approaches, as is modular programming, which uses a library of routines and processes that can be called and linked to execute an application. Both of these, as well as most low code/no code tools, are great for RAD, rapid application development.
A systems approach
What hasn’t changed over the years, however, is the need for a methodical approach in developing an application. Before you can get to a finished output product, you need to know exactly what inputs have to go into the application, and what processes need to be applied to these inputs. Two common tools used even today are flowcharting and top-down application building.
Flowcharting is something most, if not all, of you are familiar with. And it wouldn’t surprise me if many of you still have a plastic template for drawing flowcharts, or use a computerized tool such as Visio, SmartDraw or something similar.
Top-down development is also not a new thing, and this approach goes back decades. It consists of putting down what you expect the results of the application to consist of, and working backward from there to determine what data and processes are going to be needed to produce those end results.
Making it too easy?
My major concern with low code/no code tools is that they encourage a leap-in-with-both feet approach to developing an app. Sometimes this works; other times you wind up with something that looks good, and is somewhat useful and useable, but not entirely what you had in mind when you started or that completely blows up when you go to use it. The bottom line is that there’s no substitute for thinking things through before you ever put your hands on the keyboard and mouse. When you flowchart out an application, and run through it multiple times in your mind or on paper, there’s a good chance that you’ll find at least a few areas that you might not have thought about, or that the workflow of the application doesn’t give you the end product or flexibility you want and need.
Getting started
In any case, if you’re thinking of using a drag-and-drop tool, there’s a couple of ways you can approach the process. One of the first things I suggest when talking about these application development tools is to get familiar with the process before you sit down and actually start creating a useable application. That’s pretty easy to do. One language that you can play around with for a few hours is Scratch, now in its third revision — Scratch 3. You can download this or run it in a browser. Scratch was developed by the MIT Media Lab to teach “coding” to elementary and middle school students, and it’s an excellent way to quickly become familiar with modular drag-and-drop program development, even if all you come out of it with is a game. Take a look at
A similar approach is to actually use the low code tool you intend to use, and start with a vendor-supplied template, building off of it and expanding it with new features not included in the original template. This gives you a framework to build on, and shows you how the template designer approached the particular app. There are plenty of low code tools such as AWS Honeycode, Microsoft Low Code Application Development on Azure, and similar tools from vendors such as SalesForce. A good tool for getting your feet wet is Zoho Creator, as it’s both easy to learn and use, and has a large number of premade templates to use as a starting point. Zoho has also created a large number of educational materials and videos to get you going. But be sure to read the Quick Start Guide before you begin.
Whichever tool you choose (and you may choose to become familiar with a number of them), please do yourself a favor and know where you are going and how you’ll get there before you start stacking modular process blocks on your display. According to Zoho’s Tejas Gadhia, bad application design is the No. 1 reason for churn in low code applications, whether the user hits a roadblock because of poor design, or the application was not structured properly with the right connections.
Because the design aspect is one of the most important factors in application development, even with low code tools, if you do your homework I think you’ll be pleasantly surprised with what you can accomplish, and how rapidly you can accomplish it, especially with a low code tool.
