Seven codeless traps and how to avoid them

A box-and-stick trap, a mechanism used for live trapping

Put our talent to work

Programming is hard. Since programmable computers went mainstream in the 1970s, software development has required highly-skilled professionals with years of education and experience.

The problem with creating a complex computer program that solves real-world business problems is that computers and humans speak fundamentally different languages.

Computers deal in concrete terms while humans communicate in abstractions. To a computer, the meaning of a sentence never changes. But to a person, single sentences, and even single words, may have different meanings in different situations.

Over the years, providing a computer language that matches human intentions with the correct computer behavior has evolved tremendously. Each year, the methods that humans use to leverage the power of a computer become more sophisticated. These variations are all attempts at defining the ultimate programming language.

One particular strategy has its origins In the 1970s when researchers began to experiment with visual programming languages. For example, to instruct a computer to save data, you might visually drag the image of a data field to an image that represents the data storage.

The idea behind visual programming languages is that the fewer details a programmer has to provide a computer in order to perform a complicated task, the faster the system can be created and with fewer mistakes. In recent years, visual programming has advanced to the point where these tools can be used to create fully-functional enterprise systems. These software development systems are often referred to as codeless, low-code or no-code platforms.

Before you decide to invest your IT budget into a codeless solution consider the following real risks associated with these time-saving solutions.

1. Codeless programming is a lie

Excel or Google Sheets may be the best examples of a codeless software development platform. Almost anyone can quickly create spreadsheets that use simple formulas to dramatically improve bookkeeping and data reporting. These spreadsheet tools are pervasive in every business setting in America. With minimal training, an office worker can build and maintain hundreds of spreadsheets to keep a business humming along.

However, what happens when you need to connect spreadsheets, validate data entry, default data, create tasks for shipping or complex reporting?

To add complex business functionality to your stack of spreadsheets requires design and coding that an average office workers can’t do or do well. This is exactly what happens in any codeless platform.

Every codeless system has a boundary between what is possible without code and what you need a software developer to accomplish. Before you start, you must know where this boundary is on your codeless platform. If not, be prepared to be unpleasantly surprised when you don’t make it through the first week without the help of a serious software developer.

2. Data isn’t pretty

As with a spreadsheet, creating a new data entry form in a codeless platform is easy. If adding one is easy, adding 200 will be likely.

Once you have 200 forms for entering data are you running smoothly? Hardly. Data integration is complicated. Are you using a customer phone number in one form or in 200? If you change a person’s phone number in one form, will it update all of the other forms that display your customer’s phone number? How important is it that the data in your system is accurate regardless of which form is used to view it?

Managing data with precision is difficult in any software platform. Managing data becomes a nightmare in codeless systems where anyone can add a new form and create new data.

In addition to data integrity problems, codeless platforms exacerbate data performance as well. Without understanding how a data store saves and retrieves data, a codeless developer can quickly create a system that is horribly inefficient and slow.

Codeless systems typically provide canned data tuning for speed. You get some performance capabilities for free. However, as your data grows and your system slows down, your codeless platform must have tuning capabilities that you can extend to match your system needs. Make sure you have the data tuning capabilities you need and the expertise budgeted to address any problems.

3. Simpler isn’t always better

Imagine a child’s drawing sitting next to a painting by Rembrandt. Which is simpler? Which is better? Making things simpler does not always make them better.

A common problem with codeless platforms is that the first iteration of your project is trivialized. You get something that solves your lowest level need but isn’t built anticipating what your business will need tomorrow. Sometimes what your business needs in the near future is not compatible with your codeless platform choice.

Don’t paint your business in a corner by trying to save a dollar with a codeless platform that will need to be completely replaced in two years as your business grows.

4. Codeless programming platforms compound bad decisions

Software on any platform compounds dependency on the building blocks of early project decisions. Each decision you make at the beginning of a project becomes exponentially harder to fix as the project moves forward.

Codeless platforms create an illusion that software development decisions are trivial and easy. A development team will oversimplify initial project decisions because they can. Getting work “done” early in a project is more important than getting it done right.

Because getting started in a codeless environment is so simple, the decision to start building and fix it later is pervasive. Even with a codeless toolset, this becomes increasingly difficult and expensive.

You don’t want to rebuild your application three times even if you are using a codeless platform, so treat early decisions as critical because they almost always are.

5. Codeless programming environments are complicated

You are considering a codeless environment because it is easy to master, right? Well, mastering a codeless system will not make everything about computing easy. Common technical headaches with codeless platforms abound, in some ways more than traditional environments. Here are some technical headaches you will encounter with a codeless environment:

  • Version management: Some platforms don’t have any backups. If this is manual be prepared for a disaster.
  • Releasing: Is this process well documented?
  • Quality control: How do you prevent regression?
  • Testing: Are there any automated testing tools? If not, prepare for poor quality.
  • Connecting to external systems: Integration almost always requires a traditional developer.
  • Solving problems when the platform fails: If the tool isn’t working, everyone is down.
  • Designing reports: Make sure you have compatibility with the best tools available.
  • Tuning performance: Start with measuring bad performance. If you can’t measure it, you’ll likely not have the tools to fix it.
  • Licensing: Installing and scaling the development platform can be costly in addition to production licensing.
  • Developer privileges: You might think you bought every feature you need.

Releasing quality, tested software is much more than just throwing together a few forms.

6. Finding people to support you can become impossible

Once you build and release your system, what’s your plan to support it? This is the most common problem with codeless platforms. Like every language that came before it, your codeless platform will fade in popularity and eventually become obsolete.

In as few as five years, you won’t find a single person you can hire to work on your application and you will be forced to pay high fees to individuals or companies that specialize in dead technologies.

You might be thinking you can always hire development resources. However, in-house employees will leave or retire. They also have incredible leverage on salary when they are the only developer around that can service your application.

Be careful, as you have a high chance of spending more on developers to maintain your application than you would have using a traditional language.

7. Costs will be far more than you expect

Supporting your application over time will likely cost more than traditional platforms. But that is just the beginning.

Each technical hurdle you face will be more expensive to solve because there are fewer resources available that have solved these problems in the past. Specialization is expensive.

Licensing is also a huge risk. Many codeless platforms use a subscription model and often host your application for you. You are completely dependent on their pricing model. As these platforms ebb and flow in popularity, so does their pricing. The closer near end-of-life for these platforms the more desperate the company becomes and the more you will have to pay to stay in operation.

Where codeless programming stands today

We are still in the dark ages of computer programming. It takes huge effort to create, release and maintain software regardless of the coding environment you choose to use. Languages and codeless environments will improve. However, we are still far from having software development solutions that avoid all of the pitfalls mentioned above.

Choose your development platform wisely and make sure you are aware of the pitfalls of codeless choices before you bet your company on them. Traditional platforms are often the better bet after you consider all of the pitfalls associated with codeless alternatives.

Related Posts
Scroll to Top