Ok, I’m relatively new to the ‘code’ game, let alone the ‘low-code’ game. In fact, if we’re talking games, my real experience is Two Point Hospital, but that’s for another blog. But one thing as a newbie which really grinds my gears is the dwindling, but still significant voice in the development community, shouting loudly that ‘low code’ is for those too lazy or too simple (yes, they actually said simple…) to learn coding languages inside and out; it’s for those Gen Z’ers who want to pretend they are application developers without putting in the hours of learning. Built to keep the younger community happy with instant results with WYSIWYG simplicity. To stop them having tantrums.
However, as I have experienced this past few years, ‘low’ or in some cases ‘no code’ tools are finding their voice in their own right and, in many industries, taking precedence over so-called pro-code approaches to solving business problems.
Don’t get me wrong, there is and always will be a place for pro-code. Ask me to write a complex machine learning model in C# or Python (I’m assuming such can be written in these languages…? *shrugs*) and all you will get is a blank stare back, probably with ChatGPT loading the background.
Moreover, not everything can be done in a low-code approach. There are and always will be exceptions to any rule. I’m fully aware of this. In many cases, as I will discuss later, ‘low code’ tools call in favours from pro-code scripts and models more often than you might think. However, what I want to put across is that more and more of these exceptions are becoming “solveable”, and solved, by ‘low code’ approaches. The curtain rises on the Microsoft Power Platform.
From complex, data-driven cloud applications, to pixel-perfect mobile apps, Power Apps is the Power Platform’s, in my eyes, key offering. Never before have we been able to truly create an ‘App in a Day’, and even an ‘App in an Hour’, and roll this out with confidence, stability and security. Never before have people like me (and auditor for the last 15 years of my career!) been able to immerse themselves in the technology arena and achieve success, without needing a Doctorate in Statistical Analysis or Computer Science.
Why choose low-code over pro-code?
Speed of development: Low-code development can accelerate development times by reducing the amount of code that needs to be written. This can be especially helpful for simple projects or tasks.
Ease of use: Low-code development platforms are designed to be user-friendly and require little coding knowledge, making them accessible to a wider range of people, including business analysts and citizen developers.
Collaboration: Low-code platforms can facilitate collaboration between developers, designers, and other stakeholders in a project. This can help ensure that everyone is on the same page and working toward the same goals.
Flexibility: Low-code platforms can be used to build a variety of applications, from simple web pages to complex workflows, and can be customised to fit specific needs.
Hmm, but pro-coders can customise things intricately to my specs, isn’t low-code just a new name for drag-and-drop?
In some respects, yes, but I’m keen to distance myself from this response immediately after saying it. Yes, OK, low-code has an element of drag-and-drop, but why is this presented as a negative? Why wouldn’t people want to make their lives easier by using pre-built common controls in an accessible and secure way?
Again, don’t run away with the idea that low-code can do everything. If there is one thing (and there are more than one…) that pro-code still beats it’s newer brother at, it’s what I refer to as extensibility, or customisation. Professional developers can create custom solutions to complex problems that may not be possible with low-code platforms. There, I’ve said it. But let’s look at something people have spent hours in-front of Visual Studio pondering, and see how the Power Platform could have made things quicker or, in some cases, better, even if some pro-code is tacked in to seal the deal…
Model-driven apps. For Power newbies, this term makes many shiver in panic. Not much drag and drop functionality here. None of the fancy buttons and Excel-like formulas making things easy. But let’s look at what a model-driven app is. As the name suggests, it is an app which is driven by the data, not the other way around. The app isn’t built all lovey-dovey and then some data added in for good measure; far from it. A model-driven app is personally my favourite kind of Power App as the possibilities are seemingly endless, and native, automatic scalability per-device beats a Canvas app into a cocked hat. Get your data into Dataverse, and away you go. From data set to fully functional application in a matter of minutes (ok, a few hours…).
So… where does the pro code bit come in?
I’m glad you asked. Yes, a model-driven app, as an example, is very powerful and doesn’t require a single line of ‘code’ to be written in order to build, test or deploy. They scale screen sizes, can be secured down to the column or row level, and users can even customise their own local experience in the app at the click of a few buttons. But, for what a model-driven app lacks compared to it’s Canvas counterpart, along comes the JavaScript train. JS is still the only supported programming language to extend the Power Platform when it comes to model-driven apps. Want something to happen when a user opens a form? JavaScript. Want a field populated when a user starts to type? JavaScript. Want to side-load functions when your app reaches a certain stage? JavaScript.
What I’m trying to say here is that low and pro code can exist side by side, one complementing the other, perfectly happy. Neither having particular superiority. Remember, the JavaScript being used here is minimal, with the application already built, but simply being extended via JS. In some cases, Power Automate can replace JS entirely, but for true in-app customisation in this context, JavaScript is the way to go.
Let’s also take a look at Power Automate itself, now I’ve mentioned it; the modest but intelligent sister in the Power big-gun family. Many people have said to me that Power Automate is just Logic Apps for people who don’t know their way around Azure Portal. How wrong people can be.
Power Automate is extremely adept at looping through those common, mundane business tasks with ease and speed. But so are Logic Apps, I hear you cry. True. They can co-exist. Logic Apps, however, are more complicated to develop for what I’m talking about here. I’ll be the first to admit that Logic Apps win hands-down when it comes to very complex integrations and workflows; but, for those new to the automation game, Power Automate allows the benefits of workflow automation to be realised in-browser by anyone, whereas Logic Apps requires deployment. Doesn’t sound like a big deal really, does it?
Ah, well, herein lieth the difference; Logic Apps is pay-per-use, whereas Power Automate is subscription based. For organisations with a high-volume of automation needs, Logic Apps can soon run up large Azure bills, whilst Power Automate stays within anticipated pricing. Automation tasks at SMEs are becoming increasingly vast and numerous, so this is an important point. Not forgetting of course that Approvals is only in Power Automate, so if you want an approval task in your flow, forget Logic Apps from the get-go.
What I’m trying to put across here is that there are low-coders and there are pro-coders, but both can co-exist very well in same ecosystems and even learn from one another bi-directionally; not just low-code stealing some pro-code now and then. What shouldn’t be said though, if I could wave my magic wand, is that ‘low code’ is not really development. Of course it is, it’s just a different type of development which might save you time, money and hours at the optician’s stemming from squinting at VS Code in a darkened room.
2 thoughts on “Low code, with a helping hand, really is the future; here’s why…”
Comments are closed.
Really good article!!!
Good article Phil, you are rocking and best of luck 😔 may be add a few diagrams next time! ☺️