Low-Code No-Code - Power Platform UnPacked #2

In this episode, I talk to Sara Lagerquist about low code - no code!

[igor]

I think it all comes down to the complexity of the project. Simple solution should be now-code and the complex will have code all the way. There is a reason why Dev takes time and effort.

[FlipletNet]

We take a prefab approach to app building at Fliplet.com. 90% of your app should be no-code but for the 10% custom edge cases then you should be extend the core platform with code should you wish.

[rogerhill]

Three main problems I see with the "Lo-code" approach, and I'm thinking particularly Business Rules vs JS in Dynamics CRM.
- How do you version control Business Rules? If they stop working between last week and this week, how d you answer the "What's changed" question?
- Business Rules can become over complex to the point that they are impossible to understand or debug.
Bear in mind that the order in which Business Rules execute depends on the order in which they are enabled. Bit of a nightmare!
- How do you Unit Test business rules?
My opinion is to prototype in Business Rules (SFP - S****y First Prototype), but then do a proper JS implementation that can be tested and managed.

[troumacacq]

Sad, but true: vast majority of CRM developers will not pass even first round of interviews in FAANG companies. The bad news — we just not skilled enough for current industry standards. The good news — this is CRM's key selling point — any person with minimum knowledge would be able to customize a system.

Basic C# skills is enough to write a plugin. JS is not much harder, just different. You even not required to know SQL! Everything is configurable almost in drag'n'drop style! So if you aren't forced to go deeper, not forced to challenge yourself to achieve results, if you can become CRM developer from zero to hero in several month, what kind of code you will deliver?

I'm trying to say, that we're fixing lack of knowledge by giving people simpler tools. Not sure it's the right attitude, actually.

[sirkato]

Nice talk. I disagree with "code = technical debt". I think it is the other way around and I will give you my biggest concerns about no/low code.


1. No/low code has very strict borders. It can do certain actions but as soon as you reach the end of what is possible you have to tell your customer "nah workflows can't do this, we would have to rewrite everything in code". I would say a lot of customers now do not go the road of paying rewriting that stuff and then decide to not go that road. This brings us to a point where you, as the customer's partner on the road to success, are an obstacle to the customer's productivity.


2. No/low code cannot be automatically tested in a reasonable amount of time. That leads to a point where changes to an existant part of the system can get extremly costly because the testing of all possible edge cases can be drowning and incredibly dull. And dull work often means error-prone work. Today, automated testing of little code pieces or even larger feature based tests are day to day work for developers in most other businesses, like in the web development world. I heard that you cannot even deploy a plugin in sales force if you not have it unit tested. From my experience I can tell you that the CRM world so far behind on that matter and it already makes huge problems in older projects.


3. No/low code becomes unmaintainable ever so quickly. Once you reach a certain complexity, workflows and business rules, become extremly difficult to read. I have seen CRM systems with couple of hundred workflows with some weird naming rules. Some workflows became very huge and called child workflows and they called child workflows. Stuff like this is a total mess and yet so typical. And unlike code, you can't simply refactor workflows because you don't have automated tests. Mistakes a human. But with code you are more likly to fix them. Not only because of tests, but because of better tooling (debugging and so on).


4. No/low code is a pretty old concept. It is there for years and never really had a big breakthrough. It is not even Microsofts first try (Lightswitch) and maybe this time they are more successful with it. But I don't think that it will be successful just because its "such a good thing", but the lack of qualified developers in the CRM business. Consultants that are "good logical thinkers" are easier to find than good developers.


5. Last thing I like to mention that is stupidly often the case in my experience: A customer wants the exact same functionality from one Entity on another Entity. And here it can get messy very quickly. In code developers have some very basic rules that every developer has to listen to (anything else is not a developer but some kind of code shaman that 'some how get things to work'). That are principles like "Don't repeat yourself" or "Keep it simple". And that is ever so often not possible with workflows or business rules. You often have to duplicate them, let them run on another entity or form (or even multiple different ones) and as soon as you need to change it you have to change it the exact same way in multiple places. With code those very common tasks are a piece of cake, at least when you employ good and experienced developers.


To wrap it all up:
No/low code has a big technical debt because of its borders and boundaries and you may even hinder your customers success. It is not effectively testable and therefor is hard to maintain over the years. The no/low code scene is, besides it is there for years already, not as "developed in principles" as developers are.


I do think that Workflows, Business rules and so on are only the way to go for very small projects where you do not expect them to grow rapidly, like for a company with 10 Employees over the past couple of years or so. For any other case I would say "code first where possible". Also I know that not every project is the same and often enough there is not enough developers. But to be honest. Learning to code the most simple and common tasks in CRM is so stupidly easy that I think that good consultants can take care of, like hiding fields or sections on a form. Still better than using a business rule for that.

[Mohammed-zosg]

Great Discussion Thank you very much sharing your valuable information and views Regarding Low code No code.!!!?

[JelleVervloessem]

Hi, I really like the discussion since we too are struggling with the new tools and features.
One of the issues we think with lo-code / no-code is the lack of application lifecycle management. For 'real code' we can deploy in a controlled manner via DevOps, and keep every change in sourcecontrol.
We experienced this issue also with some workflows, which is why we prefer plugins and javascript above Workflows and Business Rules.
I really hope that your quest will clarify some of our questions.
(great video's by the way)

[DataSpinners]

Hey guys - great job. I'm suggesting that Low Code = Formulas and Logic i.e. something that looks broadly understandable when you look at it (as a non-dev). However, very often when you put it together (i.e. the formulas and logic) it can become a jumbled mess :)
I really dislike the term code (I use the word too), but it's the best that we've got as I think it alienates people that would be perfectly comfortable with formulas.

[ZePowerDiver]

Sara/Scott, how do you view Microsoft "pitch" which moved from solely stating Low-Code No-Code into one that covers Pro Dev, IT Dev more and more ?

Scott, the packaging of your videos / content is great, thanks and keep them coming! and.. would you actually love writing assembly code ? :D:D

[andyjabez]

If you're trying to "bridge the divide" between no/lo adherents and "real" developers, having someone come in and throw bombs and entirely specious arguments is not a great way to do it.
Apps and Flow and no/lo have their place, and they need to be used *whenever* they make sense. Preferred over coded solutions, honestly. But pretending that you can meet the requirements that would require "two years of code" with Flow "in a week" is just *awful* messaging and sets up our conversations with decision makers for failure. I'm glad she's contributing so heavily to the community: far more than I have, certainly. She should continue to evangelize no/lo. She needs to get a *lot* more education about what "real development" is and not throw around comments like "no workflows and plugins on the same entity" or "I hate JavaScript."

Here's a requirement I had recently, let's see if she can resolve it without JS.
When a lookup value is set, pull data from that lookup and provide notifications on matching fields that will "pull in" the value from the looked-up entity. I.e. the *current* shipping address from the customer? Our CSRs will see a message under address that says "set the address to 123 Jinglebell Lane?" They can ask "this still your address?" click apply and pull that address in, or they can type in a new address.
We just wrote that this sprint for a brand new client and they are *thrilled* with it.

[ambecki]

Transition form one code less Dynamics workflows to other code less Power platform is very slow. In the same time migration of plugins with automated tests goes very quickly.
I prefer code less just for very basic solutions. Good point is to follow the same rules for both dev and codeless solutions: 1. keep complexity of single component low. 2. Respect single Responsibility principle. 3. Make it easy to understand - not by comments but by the structure. 4. Test! Test is the best documentation - you can have an examples in Excel, or you can have it code but it is the most important part of the solution.

[crmkeeper]

Would like a video of your AV setup :)

[dswoopy]

No Code = Configuration debt.

Refactoring a configuration is much more messier than refactoring a code. And not always configuration follows best practice in coding standards.

[andyjabez]

You cannot honestly compare a project that can be done with Flow "in a week" to a project that would take "two years to code." Obviously, those are *completely* different requirements! That is such a specious argument.

[YTEEsenior]

Great discussion. I think pro devs should be across all design formats. No code inclusive. I feel coding provides solutions to meet requirements but MS should be refining the code to be more transparent to all solution providers and spend more effort to ensure code frameworks is sustainable over time without complex recoding efforts. This area has lost focus over no code and next pro developers will be the code to design no frameworks for none coders.

[andyjabez]

Sorry, this is ignorance, and this is from a developer who adheres to the mantra that "every line of code is a liability, not an asset." This guest is simply arguing from the perspective of someone who only has one type of experience. The entire argument is argument from incredulity: "I don't understand it, therefore it must be bad."