Low/No Code medium/high risk of headache?

Low/No code

To start of. I really do understand the allure of Low/No code platforms. I really do!

I have been working on 2 of them for the last year and a half creating smaller internal solutions, so I have some familiarity.

The idea is really good. Build a platform that is easy to use, drag and drop interface for building UI and a script based or “node” based system for doing logic. Simple! … right?

The bane of simplicity, wanting to actually do something useful.

Just to preface, I have mainly worked with the Microsoft Power-platform and Neptune as well as a smattering of other automation tools.

So this perspective comes from that.

We can start with this. I actually kind of like the powerplatform. Microsoft is still Microsoft and they don’t force you to use their tools as much as a gangster does not force you to pay for their “protection”. It would just be really bad for business if your kneecaps suddenly had holes in them. But that aside, getting small apps up and running without having to do the network, the backend, getting the user data etc etc is a good thing. Having a platform that allows for users, and especially less technical users, is great.

I made a small tool for my workplace that handles the keys to the gym lockers. Nothing amazing. There are a set amount of keys and lockers. When one is checked out the locker and its key are no longer available. Helps the office manager keep track of how many lockers there are and who has what locker. This took about 2 hours to make start to finish. Although there is not really a development process to speak of here. But you don’t really need one. You probably wouldn’t think you need an automated security and failsafe system for your kids tree-house. Small, people oriented, solutions are great to just get off the ground really quickly with these platforms.

The same with the power-automate. Introducing it to some of our more technical users that could wrap their head around making a flow was really good for them. Being able to automate small manual tasks at their own level! Not having to ask IT to make something that they don’t know how will work or how it is used every day, just automate it yourself. The problem arrives at our doorstep when we start making things complicated. And like dear Grug said “Complexity bad”.

Modern software solutions, and ESPECIALLY when it comes to business solutions. Managing people and all the systems that are needed just to make sure that people can do their jobs and get paid. So when you want to do anything that requires a bit more thought to it, maybe get some data from an api or interact with something outside of the Microsoft ecosystem. Well now the headache starts.

And I already hear you say “well the powerplatform has its limits. You can’t blame the tool if its not being used right”. If someone could communicate that to the powerplatform sales team,

The problem is often not the tool, it’s the people that decide that the tool will be used for everything moving forward, are being sold the tool like it is the end all be all of UI and software development.

“You can make anything with it easily, and you should!” - some sales rep somewhere. And I get the allure, I really do. A lot of people probably have the experience of working with a software team creating a website and they just want some content centered but it takes a week because the project manager was out of office and CSS is hell on earth to work with(totally not a skill issue on my part). And the thought of just being able to drag a button 20px down and to the center looks really nice. And it is really nice. Until you add the forbidden complexity spice.

The thing most people forget about when looking at low code platforms is the logic. It’s not sexy, if the button is pretty who cares what’s behind it. Until you start using the thing and the button goes nowhere and crashes the app. There is always logic. And in case of a lot of data … a lot of logic. Not even just a lot of data, a lot of data sources. Low code platforms often force you into something I like to call ‘UI based programming’. Instead of your usual OOP or functional programming or even scripting where you largely thing of your logic as a process, data in data out and something is done with it in the middle, UIBP forces you to think about logic as tied to and only existing to serve a single UI element. And there can be lots of logic tied to one element. In case of the powerplatform each element has numerous amounts of fields that can all have logic in them. Just about everything about an element can be tied to logic, just like in code, but you have to click and edit each ‘thing’ individually! and with a lot of elements this becomes a forest real quick.

Also just a quick note. The language they have chosen to use, called PowerFX … is crazy. I am not the best coder in the world and I have some experience with python, javascript and bash scripting. But MAN is the powerplatform weird when it comes to coding… like an if statement in this thing is

If(condition = "valuecheck", outcome-If-True, outcome-If-False)

And if we want to be as bold to do an else statement as well … we have to insert a new if statement into the outcome that we want to trigger from. Not very elegant.

If(condition = "valuecheck", outcome-If-True, 
	If(condition = "valuecheck2", outcome-True, outcome-false))

ITS COMMA SEPARATED! sorry. It’s not that big of a deal really. It works and is nicely tied into the ‘UI’ness of the whole platform. But man is that weird syntax. There are some other small gripes like how some elements are parsed name wise… but it’s honestly not that bad.

All the bad aside. Generally the problems can be overcome. At my previous workplace I had built a monster of an app that has a lot of functionality, sends emails, gets data from list, talks to multiple api’s and gets the data it needs and sends it off to our server. That is all we ask of it and it works. But getting there has been a journey. Multiple times has microsoft updated the platform and broken something. Sharepoint connections have stopped working out of the blue and connectors suddenly loosing access. The problems were partly our process. The product was not really well defined and kept changing, but there were also a lot of struggles just working with the tool. And being someone that has made webapps, makes it really hard working with something that makes basic things feel hard when you already know how to do it in code. But I guess that is always the case when working with something new.

But as the project comes to a close and you start thinking about documentation and maybe even a handover. You realize that no person on your team or within a 10 mile radius would even be remotely able to understand the entire solution without at least a couple of months and a good understanding of the platform. And creating documentation for it would not only require you to explain what and how things have been done but also where. Each button, layout and element with all of their logic and where to find that logic. It’s not in a file connected to each component or page, you have to know where to look. And if you are going to create that kind of documentation, for this app, the bible would be lighter reading.

Why do we do this to ourselves?

For one, I blame sales. There are a lot of claims that are thrown out there when selling the platform that either are not explained in context or are a misrepresentation of what the platform is or is for. Because there is a mismatch between the goals of the people selling the platform and the actual point of the platform. “Can the platform do X” the CEO asks “Can it do X? well of course it can! It can do X all day” - the sails rep says and then quietly whispers to himself ” if you are intimately familiar with our platform, which you obviously are not since I am here. So you will call me and I can send an engineer over that has excellent billable hours… for me ;) .”

But generally here are some things that either get promised or people think is inherent in low code platforms from someone who has worked with this for a little while now.

No code = low complexity

• Does it though? Does it really? This might be a bit harsh, But I think this opinion stems from people who do not, have not and will not in the future …code. So they don’t understand it. It seems hard and they don’t have the knowledge to see what the code does. But if you have a lowcode platform it can seem that you can understand better what is going on. I would argue that I could explain code, especially front end code where its tied to something visual, to someone in management than I could the same app in lowcode. IF! that app was just a little more complex than a gym locker key tracker.
  

Anyone can do it

• sure, if they already know code, or already are very familiar with the platform. So that is not really “anyone can do it” it would be on the same level as saying “anyone can code” and it would be equally true. However in the job market today there are a lot more people that can code than there are people familiar with these platforms. And if you are hiring them, why not let them do what they are good at .. code.

You don’t have to deal with hosting and network

• This one is true. dealing with directly with AD or some user database is a hassle. So if you have M356 it’s really easy to ensure safe access and just link to the powerplatform environment. But what if you don’t? what if you don’t use microsoft tech? 😮 Well here is the crux of this problem. Webapps are flexible. you make of them what you want. Going for a solution that is already built might not fit your use case or situation and this is often not considered by the people making these choices. The platform can be made flexible with much will and power… but at what cost of sanity for your IT team having to hack their way around problems instead of just implementing them in the way they want or is needed.

You don’t have to deal with devops

• Ah, yes the hate for devops. As a current devops engineer I sometimes feel like the nagging aunt babysitting the kids and begging them to STOP CIRCUMVENTING THE CODE REVIEW!! or maybe that was just my aunt? But taking away devops or the need for release pipelines is often a dream of some people, that usually resent me for pointing out that that is a dumb dream and they are lesser beings for stating so out loud. This becomes obviously clear when you start testing your app and actual users begin to use it… maybe environment separation for at least Dev and Prd would be nice. So you start exporting your solution and importing and … crap you forgot something, export again and oh the button is not centered, so we export again and now you have low disk space because you have 100 different versions of your app in your download folder. This is not good. This is manual labor that is what we are trying to avoid when making these smart solutions. So we need to make a pipeline or some process that with the push of a button takes the current state of one environment exports it, checks it and imports it to where it should be for the user to have access. So no you still need devops. For us this is a git-repo and a couple of actions that export commit and import the entire solution with env variables on either side making sure that the flows point the right way. Not too complex, but needed nonetheless.

There is no maintenance with low/no code

• There might be less, but not none. As I stated earlier, microsoft has pushed multiple updates to the platform that have broken things without warning so we had too look. Same with other platforms. There will be downtime and there will be maintenance. And it might even be just as much as with code because it’s not that easy to figure out why things break. They just do. That is the curse of being on a platform that you do not control. If you break your code it was because you pushed an update. Simple. Roll back the update when things break and fix them, repeat until nothing breaks. You even have automated testing and unit testing, code review and many many many tools built by smart people that can help with this. This being UI driven makes troubleshooting hard and tedious. Relation between elements is not always clear and what has an effect on what is hard to see.

It’s quicker than code driven development

• Arguable. Getting something on the screen is quicker yes. Actually loading up some data and doing something with it. I doubt it. An example for this argument would be styling. An html element and one css class. you can set a rule that makes all elements within that class appear a certain way. And with one other class you can ensure they look all the same. If you want to do this in powerapps, there are ways but they are not the default. And because they are not the default to users getting into the platform will not be as apparent. I know that you can create a v-box and set rules for all elements within that box. then set a gap and margin so all the elements are the same. But they do not teach you this. Thy point you to the drag and drop features of adding items in one by one moving them by hand and then having to adjust the length of 40 different things when you change one because they are supposed to look the same. It’s not intuitive. and if you are creating boxes and variables for the default lengths for your buttons and inputs would you not … and I can not believe I am saying this … rather … just use css??? 🤢 Like I hate css and each project I work on shortens my lifespan around 3 months because my grug brain cant workout how to flex things correctly. That is a massive skill issue on my part. But even someone like me sees that the low/no code way of styling is either easy and not flexible at all (it looks this way and ONLY this way) or its flexible but a hassle to work with to a point where you long to just

  .letMeCreateClassesPls {
  	display: flex;
  	flex-direction: nowhereFast; 
  }

My main point in this long winded article is this. We need not be afraid of code. Code is wonderful and lets us take complex problems and create hopefully not too complex solutions that work for us. Low/no code platforms are fantastic for just solving something simple and getting it off the ground asap!

But let’s not let people tell us that one is entirely replaceable by the other. Let’s take ownership of our needs and the solution for them. And when the question comes of who is going to maintain and build this thing. You cock a smile, look them in the eye and say “we, we are going to do it” 😎😉