ProCodeNoCodeUnite

I write this post as a response to Scotts article.

People theses days call me a “pro coder” or “pro developer”. What this actually means? I don’t know. I don’t know why “citizen developer” is a thing now or what it means. For me this is all marketing stuff made up by microsoft to sell more. To give “power user” a new flashy name. Personally I could not care less. Same user group, different name. Developers had some “rebranding” aswell in the past years. Like software developers became software engineers or software craftsman. So the “pro developers” had their fair share of “reidentification”.

For me “no code” or “low code” has nothing to do with software development. Developers that use flow or canvas apps are no software developers. They use tools to create business logic. And there is nothing, really nothing, bad about it. When I work as a doctor, I don’t call myself “low chemist”, i am a doctor. I use the medicine created by others to do the best for my patients. Those are different domains, different skills needed, different professions. They work together for the sake of the “end customer”.

What really bothers me

It’s the lying about this “LessCodeMorePower” phrase. It is totally misleading and the worst is, that customers actually believe that. In one of my current projects we decided to go with the “customizing first” approach. Meaning whenever something is doable with customization only, we do it with customization. For example when something can be done with Flow/Power Automate, we use Flow/Power Automate instead of a plugin. The customer explicitly requested it that way, because consultants and sales people from competitors told him with flow he could alter and manage their business logic by himself, showed the marketing material about how easy and cool flow is.

When you are a “citizen developer” you would probably agree, when you are a “pro developer” you probably know what comes next.

We used flow alot

So from the beginning of the project we used flows, business rules and workflows whenever we could. We made quick progress, team member without programming skills could instantly start implementing business logic. Or could they? Here comes the first issue. We had a lot of people on team that were not trained developers. They made a lot of minor mistakes when it came to basic “developer skills” like error handling and value checking. We had a quick start but soon realized that even with “LessCodeMorePower” you need a basic understanding of how data flows are processed.

Initially fast

As said, we were fast in the beginning, had some issues early but learned our lessons. After a couple of weeks the problems start to grow. The number of workflows, flows and business rules start to grow. Some things could not be done by using out of the box tools and had the be solved with plugins or scripts. Soon we had the issue that when someone had to fix a bug he or she had to first search with what tech something was implemented. After a while we lost a lot of our initial velocity.

Flow and professional software

When it comes to professional software, I think everyone would agree that having different systems, like DEV, TEST and PROD, is crucial. If you are a “somewhat modern” software developer you would also add automated testing and automated deployment.

Here it becomes very problematic with flow. You see, flows are not really ALM ready in any regard. You can have them in your solution, export them and with the help of the solution packager you even can manage them in your version control. So far so good!

When you deploy a flow in another instance in the same organization, you have to manually update EVERY flow. Every time.

You see when deploying a new flow in another instance I totally get that this one needs to be updated. But updating an existing flow as well? That kills flow for me entirely. This brings us back to “Weekend updates” when no users are working. This kills everything developers have worked so hard over the last years. Initiatives like “#NoDeployFriday (I am not associated with that)”, DevOps, Docker and what not becomes obsolete.

You might argue now that Sara Lagerquist wrote an article about how to deploy flows without updating the connection. We use that approach as well, at least where it is possible.

Other issues we had with flow

I will not go into detail, simply list everything that happend in the last year with flow for us.

• Some basic connectors became premium all of a sudden, increasing the cost
• CDS connectors are different, sometimes you have to use A, sometimes B
• SFTP connector is so bad, it fails ~25% of the time with “Bad Gateway”
• Simple tasks become unreadable and unmanageble in flow
• Error handling increases complexity of flows
• The ui in creating dynamic content/variables is to tiny to work with sometimes.
• There is no good way for automated testing in flow.

Flows are very hard to maintain. The following images shows a flow that created a record, relates the record with other records of an account and than creates another record and relates it to the initially created record.

It is nice that we could create such flow in the first place. But this is not maintainable. We also tried “flows that sub flows”, it gets even worse.

The same goes for canvas apps

All of the above and more affect canvas apps aswell. You can look at this video recorded by Paul O’Flaherty. He is revealing a lot of issues, especially when it comes to using it in a productive environment. Here are my main concerns for canvas apps

• No ALM featues, no automated testing
• You can not work as a team on a canvas app
• Canvas apps are full of “work arounds”, often called “hacks”
• Canvas apps do not support current web/app standards
• Making a canvas app looking somewhat acceptable is to much hard work.
• Canvas apps have such bad performance on devices
• Hard limitations like “One canvas app per form”

The community is young

The community around the power platform is still young, best practices will arise like it does in software development. Microsoft adds new features every now and than, the community is very active and a lot of people seeing power apps as a chance for them in the Microsoft space.

Dishonesty with flow

Here comes my biggest concern with flow and canvas apps. Microsoft and the community (at least most) are not honest when it comes to flow. Everyone is hyping everything, microsoft is pushing people that use flow. I will give you an example. At the recent Microsoft Power platform Online conference 2020 there is a talk about ALM for low code solutions by Sultan Al Sharfi (THIS IS NOT MEANT PERSONAL IN ANY REGARDS TOWARDS THE SPEAKER!). Not one word mentioning any issue with ALM and low code stuff. Now people assume that CI/CD is a thing with canvas apps and flows when it’s not.

Flow / Power Automate is not production ready when it comes to high quality big real world software projects.

I really don’t know what type of projects you work on and if flow or canvas apps are good for your case. I mostly work in projects where a team of talented people work for months or even years for the same customer. It is important that our tools and tech are optimized for teamwork, continuous deployment and automated testing. When you projects only last a couple of weeks and you changes or updates are rare flow and canvas apps might be sufficient enough.

Not all is bad!

I don’t want to close only showing the negatives of canvas apps and flows. The screenshot above is from a 24h hackathon where I, for the first time, tried to make a canvas app with a flow. The app was about scanning bar codes of backup bands and connecting them with customers to keep track of what customer is backed up on what band.

We did it in 24h, as a team of 3, tho I am very sure I would have achieved the same, if not better, result with my usual code tools. The thing is if I would not have any coding experience I would take way way way longer to achieve a working mobile app. So a canvas app would at least enable me to do something if I am not a software developer.

So using canvas apps to create simple prototypes is extremely good. It can help you getting fast feedback on the structure of an app. Even with nearly no coding experience you can create small and simple canvas apps. To sum it up: Canvas apps are a great tool for everything that has a complexity of a “business card reader” app. For everything else you should go for investing in “pro developers”.