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.
Applications icons are displayed on an Apple Inc. iPhone in an arranged photograph taken in the Brooklyn borough of New York, U.S. Photographer: Gaia Squarci/Bloomberg
Gaia Squarci/Bloomberg
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 …….
Source: https://www.accountingtoday.com/opinion/should-accountants-be-coding-their-own-apps