Microsoft's promise is beautiful! The tools of the Power Platform (Power BI, Power Automate and Power Apps) can be used directly by representatives of the teams, known as "business". They are users of the information system.
Some have a particular appetite for process management and IT, without being geeks or having developer skills. This profile is called the "Citizen Developer" or the "Power User" (Microsoft style).
Is this the end of the developer profession?
Before being a Microsoft 365 consultant, I was a developer for several years. And like any self-respecting developer, I have certain reflexes that are well anchored. These reflexes are sometimes the opposite of simple, at least in appearance. They require development experience to acquire them.
At my clients', I regularly take over Power Apps made by Power Users. Most of the time, these applications are globally functional. Microsoft's promise of "Citizen Developer" seems to be kept! However, some subtleties are often poorly mastered... This can cause problems, more or less disabling for the evolution and maintenance of Power Platform applications. This creates what is commonly called a "technical debt".
Here are my top 5 of these "subtleties", why this is a problem and how to fix it.
1. Rename the components
The first subtlety (and I always encounter it) is the lack of naming convention for the different components. For each component created, Power Apps automatically generates a name that allows it to be reused in different actions of the application.
For example: I create a TextBox. This one will be called TextBox1. If I create a second one, it will be called TextBox2, and so on.
If your application has only 5 components, it is not a drama to keep the default names. On the other hand, when you multiply the screens and the components, it becomes more complex to find your way around and not to mix all the components. And if you implement calculations from component values, it inevitably becomes a real headache and a bug factory.
A developer is used to defining naming conventions* in order to have an understandable and therefore easily maintainable code.
*NB: the definition of a naming convention also extends to the different variables created in the applications.
What I recommend as naming rules on Power Apps
Component name = a trigram to identify the type of component (Txt for TextBox for example) + the name of the screen (indeed, components are global to an application and not specific to a screen, which can be quite confusing) + a description of what the component does.
For example: I have a Label component that displays a title on the home page. I will call it: LblHomeTitle.
This work may seem tedious, especially when the goal of using Power Apps is to optimize the "Time to Market" to the extreme (develop on D-Day and use D+1, which is possible with the Power Platform). However, this time is quickly amortized as soon as the application is updated after several weeks / months. Even more so when it is someone else who does this update.
Conventions are not a developer's whim. They are the promise of medium and long term scalability and maintainability. Since Power Platform applications are bound to evolve rapidly, this good practice is essential.
2. Manage code errors
The second subtlety concerns error management. For a given functionality, a Citizen Developer will think about managing the passing scenario. If he is a bit seasoned, he may think about handling some obvious functional errors. On the other hand, a developer will be used to cover some cases of usual technical errors.
For example, a screen must display the result of a division. The Citizen Developer will be able to display the result of the division without any problem. On the other hand, it will not necessarily have the reflex to cover certain basic errors. Such as, for example, division by 0 or operands that are not numerical.
Moreover, a developer will always know how to trace errors correctly. Either for the user (clear error message) and/or for the administrator (detailed error log).
Good error management is a golden rule for the developer which absolutely concerns the Citizen Developer. It will allow you to avoid bugs (upstream tests integrated into the code) and to repair a buggy application very quickly (thanks to the error log which will quickly indicate the faulty component, easy to isolate for correction).
3. Comment on the code
Here, we are still interested in the maintainability of the code (key subject). This issue is partly related to the first recommendation (naming rules), but it is more global.
Generally speaking, developers speak a common language using common rules learned in school and also during their professional experience (rules of syntax, algorithmic or cutting, code comments etc.). For years, developers have been judged and raised by their peers. This has allowed them to understand and adopt common practices in their work. Ideally, a program made by developer A should be modifiable by developer B, without explanation, thanks to this common culture towards code.
For a Power User X, this is something that is not at all intuitive. He will create his application in the clearest and most understandable way for himself, which is not necessarily the same as for his neighbor Power User Y.
We are not going to solve years of practice and learning by "Power Magic" with the Power Platform. But as much as a good understanding of syntax, algorithmic rules, and cutting rules cannot be learned in 5 minutes, it is quite simple to comment the code well. A well commented code (I know that this subject is controversial between developers) improves the readability and the understanding of what is coded between two Power Users X/Y.... And even for the one who has to go back to his own code months (or years) later and understand what he wanted to do and how...
Commenting on its code for a Citizen Developer is an easy lever to greatly improve the maintainability of its applications and the ROI (Return On Investment) of the Power Platform.
4. Create distinct environments
Always with the aim of optimizing the Time-to-Market, Microsoft has created a concept of environments.
The default solution is a bit extreme: we have a single environment that hosts all applications. For a Citizen Developer, this notion of environment seems abstract and is not at all intuitive. For a developer, it is fundamental. Just as you don't adjust your car's brakes while driving, you can't update your applications while using them.
Hence the division into at least two separate environments by the IT teams: development and production. Often, we add a few others if it is useful for more sensitive applications: maintenance (separate from development), acceptance, even training...
By default, the Citizen Developer codes directly in the production environment of the Power Platform! However, he must make an application that is already in production evolve without impacting the other users of his application unless he wants to trigger a storm at the support team! In this case, it is therefore interesting to create other environments to manage this delivery process and to clearly distinguish between the development, acceptance and production phases. This also makes it possible to segment access to the different environments.
Technically, an "environment" is a cloud storage space in Microsoft 365, where access is segmented, on which Power Apps and/or Power Automate streams are hosted.
NB 1: The same application in 2 different environments will have the same data sources by default. You must therefore be careful to update the data sources when you move from one environment to another (production data sources VS development or maintenance data sources for example).
NB2: The creation of environments requires a Power Apps Premium license.
5. Performance optimization
Here again, the concept of performance may seem a bit vague to the Citizen Developer... It is usually the "problem" of computer scientists to provide high-performance applications.
But the Citizen Developer can't ignore it as soon as he becomes an application designer-developer. He has to pay attention to the dimensions of the manipulated data, and to the way of doing it.
Performance is a rather subtle subject with Power Apps because it intervenes at several levels:
- The first is the right choice of data source. I often see users wanting to switch an Excel file to Power Apps while keeping the original Excel file as their data source. As a general rule, I recommend using SharePoint as the default data source on simple models or the Dataverse if the company has Dynamics licenses, which is the most optimal source for Power Apps.
- The second is directly related to the quality of the code. There are often several ways to retrieve collections of data. And generally a Citizen Developer will use a loop to rebuild a collection, which may seem more intuitive, even though there are query mechanisms that allow you to get what you want directly.
- The third is what I call the threshold effect. By default, Power Apps sets a query threshold of 500 rows. In reality, you almost never need to query more than 500 rows. Nobody is able to read 500 rows at once (or even to display 500 different rows visible on a screen). It is therefore very often relevant to reduce the volume of its requests by adding filters and thus optimize the performance of the application.
Beyond this top 5, I could have mentioned other subtleties such as security management. Or the ability to determine if a use case should or should not be implemented in "low code". Or the mastery of the application delivery cycle, etc... But taking this top 5 into account will already greatly facilitate the quality, maintainability and performance of the code for the Citizen Developer.
To answer the question at the beginning of this article, " Is this the end of the developer profession?"
In my opinion, the answer is no... the developer's profession must reinvent itself to adapt to low code - no code. And the Citizen Developer must adopt some of the developer's practices to produce a better application.
A profile is emerging in this low-code movement: No Code Ops.
He is in charge of leading application creation workshops with business users. He/she is also responsible for advising them on the best practices to adopt in order to have robust applications. Such a profile also allows the IT department to have control over the applications created, in particular to apply the good practices seen above, in terms of security and to avoid the "Shadow IT", which can very quickly grow with Power Apps or other low code - no code tools on the market.
