I’ve been a developer my whole life. I worked for various enterprises to develop applications. Later on, I’ve started my own software development business and built up a team of developers working for industry-leading enterprises as well as governmental organizations.
More than a decade ago, I’ve started to work on VisionX, a Low-Code development platform. Back then it wasn’t called “Low Code” as the Low Code industry officially hasn’t had that name yet.
In the last few years, the Low Code industry is increasingly booming, and more and more enterprises and organization make the switch towards Low Code tools. While we are stoked about this movement, we see a recurring pattern of concerns and prejudices. Mostly from developers.
In this article, I’ve collected those statements and provide my view on that. Let’s get started.
“Low Code only works for simple applications”
Being one of the most common statements, I also believe that it’s a statement that isn’t true. Sure, there are simple no-code or low-code platforms that aren’t a real fit for enterprises.
However, the leading Low Code platforms have everything it takes to build enterprise-grade software:
- Data modeling interface
- Access to code as well as visual development possibilities (everything in live sync)
- Business logic & Workflow
- Client & role management
- Support of all major databases & technologies
- Scalability
- Many more
Building enterprise-grade applications sometimes require specific add-ons and features as well as user management specifications. While some developers might think that those specific requirements can’t be met with a Low Code platform, we’ve proven them wrong every single time by offering the flexibility and openness to simple program add-ons on top of Low Code.
There’s one important note here: Low Code does not necessarily mean developing apps only through drag & drop / visual interfaces. Low Code still allows developers to jump in and do the classic programming themselves.
“Low Code doesn’t work for us”
If you work in Low Code, you probably heard that one before. “Yes – that sound really like a great solution, but it simply doesn’t work for us.”
People might say:
“It doesn’t work for us because it’s not meeting our security guidelines.”
“It doesn’t work for us because the business team is requesting this super-duper complex feature that I can only program myself”
“It doesn’t work for us because we need single-sign on by default and you don’t have this by default.”
“What if …”
I could go on and on here. The main pattern I see is the following.
Developers are detailed-driven people with an analytical mindset.
When being presented with something new (=something they don’t know in detail), they will go in and analyze your suggested (Low Code) solution to a maximum extent. And that’s great as they will be the critical person in the room asking questions like “Does this work for XY?”, “How does this behave If I do this?”, etc.
And while analyzing your Low Code platform, they will run into limitation and situation where something isn’t possible in the exact same way as they used to handle it.
Don’t get me wrong. I’m a developer myself. And I know that sometimes we rush too fast to into certain directions while forgetting the bigger picture.
Maybe the way we used to run this application is outdated anyway. And maybe doing things a bit differently makes things more effectively for the people using the system.
My takeaway is that the statement “Low Code doesn’t work for us” mostly means “Low Code does things differently as I’m used to.” If we keep hearing this, we try to get the discussion to the real question: “How can we build something together that works for the person using the application as well as for the team creating it?”
“I don’t like to program software with Low Code”
That’s a tricky one, to be honest. Depending on the setup, we – as a Low Code platform provider –present our solution to a mix of roles, mostly a mix of roles between business deciders, development leads and developers.
As an organization/team making the switch from traditional programming to Low Code it not only requires process change, but also cultural changes within the company.
And the statement “I don’t like to program with … Low Code” is definitely a cultural topic. Again, as a programmer myself I totally understand the statement. I don’t like change either and I do see the prejudices of not liking the idea of visual development. Just please let me do the programming in my IDE.
Developers, however, overlook the fact that Low Code doesn’t equal visual development (in GUI designers) only. Sure, citizen developers and business teams can jump right into the Low Code platform and build their own app through drag & drop. And actually, that’s a great thing – especially if you’d like to build a prototype to quickly discuss a new project.
With modern Low Code platforms – such as VisionX – you can simple go into the IDE and always be in sync with the GUI designer (that your non-developers can use). In this case, VisionX and the Java code are always in sync, in both ways.
Summary
The mentioned statements are the result of certain concerns (does it really work for us?) and prejudices we see on the market. One of the big reasons for business teams to invest resources, knowledge and time into the Low Code movement, is the ease and simplicity of building applications. And while visual features and drag & drop interfaces are the big selling point for them, it’s the absolute contrary for developers. But that’s just half the picture.
Low Code platforms that provide the flexibility and openness of allowing developers to simple keep their IDE, are set for a successful future. I truly believe that all in all, Low Code brings development teams, business departments and deciders closer together, minimizing Shadow-IT and the communication gap that exists.
Now over to you: Which statements do you keep hearing over and over again?
0 Comments
Leave a reply
You must be logged in to post a comment.
