Low-code for coders
Oxymoron? I think not. Let me explain.
Software developers tend to be very skeptical about low-code tools. Every time a new low-code or no-code platform comes out, its founders announce with big fanfare that they have created a panacea for the developer shortage, and that writing code is no longer required. CEOs and CFOs get excited because they think they found a way to cut cost, CTOs and developers get frustrated because, yet again, they have to explain why the new tool won’t solve all of their software development problems and why “real” programmers will still be required.
It is a battle that has been raging since the days of Apple’s HyperCard. Software engineers generally do not like these tools, and can be very passionate in their defense of manually writing code. Just take a look around the developer forums – anytime a new low-code tool is introduced, there is a pretty good chance it will get shredded, if it gets attention at all. There are a number of reasons for that, and being coders ourselves, we certainly don’t disagree with them:
1. Restrictions – this is the most obvious point. Even when a low-code tool claims to give developers all the flexibility they need, there will still be a trade-off associated with visual design that needs to be considered. Coders often have their own way of doing things, and they balk when their creativity is restricted.
2. Writing code is the easy part. What really takes time is figuring out what the client wants, accurately specifying the problem, and defining a solution that not only works from the user’s perspective, but also fits into the company’s IT infrastructure. Faster coding does not help with any of these.
3. Security and other issues. This one is obvious to software engineers, but is often more difficult to explain to business units. We don’t want a bunch of apps floating around in an uncontrolled way. Security is a concern, as are performance, scalability, reliability, compatibility quality, and maintainability. And of course, we want to avoid vendor lock-in.
The real benefit for developers
Given these concerns, it is no surprise that developers often strongly resist the introduction of low-code platforms. The preference for the status quo can lead to internal battles between IT and upper management. But this conflict misses the point: for developers, the real benefit of low-code is not only its ability to speed up writing a few lines of code, but the improved cooperation with business units. Involving users in the development process has a number of benefits:
1. They actually get what they want. If the person who uses the application is involved in the development process in a meaningful way, the final result is more likely to be the product they actually need.
2. Buy-in. Just like we as developers don’t like to be told how to write code, business users can get frustrated when they are forced to use tools that don’t work for their processes. Having them involved in the development will result in much better acceptance of the final product.
3. Better communication. Business users often have difficulty explaining what they need in terms that are useful to a developer. Allowing them to build their own prototypes means they will better understand the process and will begin to communicate better when it comes to feature requests und updates. They might even hold off on asking for features they don’t really need.
Get the users involved
Here is the thing – they’re already doing it anyway. We know shadow IT is out there. Some users, especially engineers and accountants, can be extremely resourceful when it comes to clever ways of using excel and other software to further their cause. That’s all fine to a point, but we know about the amount of data that is lost by the lack of coordination with IT. Not to mention the security issues.
On the other hand, harnessing all of that creativity can 5-10x our development capacity, improve relationships with business units, and make sure that data is kept in the right place.
Facilitating the interaction
With that in mind, we should think of low-code tools less as “development accelerators”, but more as facilitators of communication with users.
But how do we really make that cooperation happen? There still is that trade-off between the speed and simplicity of a visual designer, and the flexibility of manual code. Most low-code/no-code tools are on the former end of the spectrum, focusing on simplicity, and will therefore remain in the “only works for basic applications that are needed quickly” category. For the interaction between IT and business to work, we need a platform that is easy enough for users to understand, but offers sufficient flexibility to avoid restrictions on development.
There are a few other factors that need to be considered:
1. The interaction has to go both ways. A standard code generator is not enough if it cannot translate changes to the code back to the visual designer. Otherwise the interaction stops the first time the code is manually adjusted.
2. The generated code has to be of sufficient quality. Developers often complain about the garbage code that is created by code generators, so the bar here is set pretty high.
Meeting all of these requirements is a tall order. Our next post will explain how we address them.
0 Comments
Leave a reply
You must be logged in to post a comment.
