Should Accountants Code Their Own Applications?
I have heard about the current trend in application development using a low code or no code approach. This gets a lot of attention from accountants, as developing a usable application traditionally takes a lot of effort and time. In the past, many accountants have turned to spreadsheets to eliminate a quick and dirty application.
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, low code / no code systems use graphical programming to drop packaged processes into a workflow. to create the application. It is often presented as almost effortless.
I have to admit I’m a bit on the fence with this approach. Much of this hesitation comes from my past. I started a long time ago as a programmer, analyst-programmer and PD manager before going back to school for my accounting degree. Largely self-taught, I have programmed a number of business applications such as accounts payable and receivable, general ledger, and construction payroll, in nearly half a dozen computer languages. In fact, it was the desire to better understand the processes of these and other applications that sent me back to school for a degree in accounting. And I was a very young user of program builders like 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 (who really doesn’t have a job).
In many ways, these early programming tools are similar in approach to many low-code / no-code approaches today, as is modular programming, which uses a library of routines and processes that can be called. and linked to run an application. These two tools, along with most low code / no code tools, are ideal for rapid development of RAD applications.
A systemic approach
What has not changed over the years, however, is the need for a methodical approach in developing an app. Before you can get a finished output product, you need to know exactly what inputs need to go into the application and what processes need to be applied to those inputs. Two commonly used tools still today are flowcharts and top-down application building.
The organization chart is something that most of you are familiar with, if not all of you. And it wouldn’t surprise me if many of you still have a plastic model for drawing flowcharts, or use a computerized tool like Visio, SmartDraw, or something similar.
Top-down development is not new either, and this approach dates back decades. This involves writing down what you expect from the results of the application and working back from there to determine the data and processes that will be required to produce those end results.
It’s too easy ?
My main concern with low code / no code tools is that they encourage a two-foot hopping approach to developing an application. Sometimes it works; other times you end up with something that looks good, and is somewhat useful and usable, but not quite what you had in mind when you first started or that blows up completely when you go there. ‘use. The bottom line is that there is no substitute for thinking before putting your hands on the keyboard and mouse. When you organize an app and go through it multiple times in your mind or on paper, chances are you will find at least a few areas that you may not have thought of, or that the workflow of the app doesn’t give you the end product or the flexibility you want and need.
Either way, if you plan to use a drag and drop tool, there are a few ways to go about the process. One of the first things I suggest when talking about these app development tools is to familiarize yourself with the process before you sit down and start building a usable app. It’s pretty easy to do. One language you can play with for a few hours is Scratch, which is now in its third revision – Scratch 3. You can download it or run it in a browser. Scratch was developed by the MIT Media Lab to teach elementary and high school students about “coding”, and it’s a great way to quickly get familiar with drag-and-drop modular curriculum development, even if all that you get out of it is a game. Take a look at https://scratch.mit.edu for more information. The example projects are, for the most part, geared towards games and children, but you can actually build some pretty fancy applications using Scratch, and it’s a great learning tool for the low code approach.
A similar approach is to actually use the low code tool you intend to use and start with a template provided by the vendor, building it and extending it with new features not included in the template. ‘origin. This gives you a framework to build on and shows you how the model designer approached the particular application. There are many low code tools like AWS Honeycode, Microsoft Low Code Application Development on Azure, and similar tools from vendors like SalesForce. Zoho Creator is a good tool to get your feet wet, as it’s both easy to learn and easy to use, and has a large number of pre-built templates to use as a starting point. Zoho has also created a number of teaching aids and videos to help you get started. But be sure to read the Quick Start Guide before you start.
Whichever tool you choose (and there are any number of them that you can choose to familiarize yourself with), do yourself a favor and know where you are going and how you will get there before you start stacking process blocks. modular on your screen. According to Zoho’s Tejas Gadhia, poor app design is the main reason for unsubscribing from low code apps, the user runs into an obstacle due to poor design, or the app was not structured properly with the right connections.
Because the design aspect is one of the most important factors in app development even with low code tools, if you do your homework I think you will be pleasantly surprised at what you can accomplish and how quickly you can accomplish it, especially with a low code tool.