Low Code and No Code Development Trends

Tyler Throckmorton

Software Developer, Healthcare Leader, Golf Enthusiast, Foodie

Last time we discussed how scoping and requirements are perceived by developers and their outsized impact on the process of delivering a functioning solution. We learned that, as a software developer, requirements are paramount in defining the request in a way that makes sense and is small enough to be manageable in individual bites of work. But how does this idea change if we didn’t need to code? If we don’t need to code, do we still need software developers? To answer this, let’s first think about what a software developer does.

A software developer codes. Right? Well, yes and no. A software developer does write code and build websites and applications and application programming interfaces (APIs). But a good software developer figures out when to not code. They realize that their job isn’t about writing code, but about solving a problem. The most efficient way to do this is to do as little as possible. So a good developer works to understand the problem and design a solution around fixing that.

Now that we know what a software developer does, let’s think about our first question. What if we didn’t need to code and used a low or no code software framework? First, remember that a software developer doesn’t code first. Even in low or no code environments, all of the same questions exist. What is the problem we’re facing? Why does this problem exist? The answers to these questions and many more are what you pay a software developer for.

If you’ve read my previous articles, you’ll remember my recurring example of our telecommunications and CRM integration. Let’s imagine now that we want to create this system using a low or no code system. What would be our first step? Initially, many might say to find a system that says they can or have experience implementing solutions like this before. However, I wouldn’t. My first step would be to meet with the stakeholders. The problem needs to be defined first. What are we trying to solve with this? Do we need a system that can just answer the phone and we write notes into? Do we need a system with prebuild tasks for specific actions your agents may take during their day? Do we need a system that tracks user sentiment as they interact with your agents? These are all viable business cases but each case may be better suited to a different product. This doesn’t mean one product can’t do all of these, but you have to strategically pick your battle and decide what problem you are trying to solve and who or what can do that the best.

Over the years, I’ve seen my fair share of these products. Low code and no code solutions aren’t something new, you know. Remember Windows Forms? That’s from the early 2000s and was probably one of the most recognizable solutions for the beginning of this. However, it’s not even the earliest. There’s Visual Basic from the 1990s where companies often would visually design software through drag and drop controls. Even before that, and it might surprise you, but Microsoft Excel was the major turning point to low code and no code solutions when it came out in 1985. Excel, at it’s core, created a way to code math without having to do it manually. Just click a button and the entire column is now summed up into one cell.

Now you might say, Excel isn’t coding. And now, you might be right. But 40 years ago, this was revolutionary. Now in the 2020s, our low and no code solutions are much smarter, more intuitive, and substantially more complex. That still doesn’t mean they’re the right solution. If you look at history, one of the things you’ll notice is that the trend of low and no code solutions has an ebb and flow. Companies wax and wane from using them to not using them. In the early 2000s, Visual Basic and Windows Forms was all the hype and companies used them everywhere they could. By the 2010s, a lot of companies were reverting back to coding as many would originally have seen it – software developers were finding the problem and coding a solution out to fix it. But by the time we reached the 2020s, these solutions had started to make a comeback again. A major reason for this was the success SalesForce had started to have. SalesForce has been around since the early 2000s, but they finally broke through to the market and started to be massively successful in the mid to late 2010s. As a result, you started to see other solutions crop up that began to design their own market with the same concept.

Personally, I think the restrictions that these kinds of solutions place on you really are detrimental. However, they have their place in the market. Companies have historically had to pay millions of dollars and spend years building a solution due to how complex of a problem they’re attempting to solve. With the advent of these low and no code solutions, they’re be advertised and marketed as being able to solve the same problem in a fraction of the time. As a result, companies are using the product because it allows them to get to market faster with the solution to their problem. After they reach market, then a decision is slowly worked through about how they could do this more efficiently without the limitations of the solution they have now. This in turn creates the cycle we’ve discussed before. The ebb and flow of low and no code solutions is baked into the economics of our society.