News

Graphical Programming Naturally Fits with Infrastructure Automation

Graphical programming—or low-code/no-code programming—is excellent for education. When you’re trying to get an 8-year-old to understand programming logic and what software development can accomplish, the ability to create something concrete without spending months learning a programming language or debugging typing or syntax errors is powerful.

When you’re trying to develop a business application, one that has specific, pre-defined business logic associated with it, graphical programming will usually only get you 90% of the way there. When we’re talking about a business application, that isn’t enough. And in most graphical programming platforms, going from 90% to 100% is exceptionally hard.

Graphical programming means taking pre-written blocks of code that are exposed as graphical icons and can be drag-and-dropped onto an application canvas. It makes it possible for non-programmers to visually understand application logic. In an enterprise setting, this has often meant a business person asks a developer to create an application that adheres exactly to the graphical structure laid out in the low-code/no-code environment.

It turns out, though, that while this approach is great at getting approximately what the business person wanted, there’s usually some key functionality that’s missing or not working correctly. So while the developer can save some time getting the first 90% of the application done, he or she spends so much effort taking the application from “almost” to “done” that any productivity gains are lost.

In addition, most enterprise no-code platforms don’t end up being “no-code” at all. They usually include a “custom code” box where the developer can drop in code. In practice, many developers asked to use no-code platforms will just have three graphical icons on their canvas: start block, custom code filled with regular code, and then the end block. While asking schoolchildren to write code is a heavy lift, most professional software developers have no problem writing code from scratch.

 

Opening the Black Box

The main problem with low-code/no-code options is that the individual code boxes can’t be changed. If there’s something interacting in an undesirable way with another part of your application or with your data, it’s very hard to debug.

From the outside, Agile Stacks might seem like just another graphical programming option because our Control Plane UI has icons representing whole applications and tools on the backend. It does give business people the visual interface they want by providing a graphical view of the entire application stack. But Agile Stacks does not have black boxes. Once a developer creates an application, he or she gets the code generated by the Agile Stacks’ platform and can go back in and edit where necessary to achieve the business goals or overcome infrastructure limitations.

 control_plane_kubernetes

Image: Agile Stacks' Control Plane UI translates what used to be CLI keystrokes to a click-to-deploy effort in minutes.

 

This provides the best of both worlds. Business leaders get their visual interface. Developers get a faster development environment—using graphical programming that will get you to 90% done faster than writing code from scratch. But those gains aren’t lost in an effort to get exactly the functionality your business needs: all of the generated code is available for editing in the Git repo we set up for you.

Want to see what you could do with an intuitive programming interface that still gives you 100% control over your final code? Try Agile Stacks.

Topics: Application Composition, Business Agility, Enterprise Applications, Enterprise Software, PaaS, Reducing Costs of IT, software development, DevOps First, Full Stack Deployment, DevOps Automation, Machine Generated Code, Infrastructure Automation

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all