I have seen a few “robust discussions” among developers about Microsoft’s take on Fusion Development. I thought I would review what it is and where I think Microsoft is on the right track.
What is Fusion Development?
The high-level notion of Fusion Development is familiar to anyone who has developed/implemented a software application in an Agile framework; developers and users/Product Owners working together to achieve a shared vision. The key difference, as I see it, is the Product Owner evolves from simply dictating the requirement, and approving the development outcomes, to being more actively involved in the development process. Rather than being outside the development team, they become part of it and more involved in the development process.
Microsoft has some learning modules on Fusion Development where they describe the ideas behind it. This module has the below diagram, which captures the concept pretty well.
Tools like the Power Platform have encouraged this evolution by effectively merging prototyping tools and development tools into one. A user can put together a rough frame of what their vision for an application is and, when they reach the limits of their capabilities, a developer can take over to smooth off the rough edges and make it practical.
The biggest complaint I hear from developers about letting users loose on the tools is their ignorance of development practices. Similarly, I hear of organisations letting users loose on tools like Power Platform to build apps to meet their needs with disastrous results. While great apps are built, without governance in place, there is the risk that an app will fall foul of internal policies, or worse, the law. In the worse case scenarios, the apps have to be scrapped because, for example, Personally Identifiable Information is not being managed appropriately. No one wins. IT are seen as the destroyers of innovation and the users get a taste of something better only to have it taken away, demoralising them and discouraging them from engaging in future development.
This talks, of course, at the need for good governance in place in terms of software development, and data management. For the developers who have concerns about cowboy user development, they can set up a framework for the user to work in. For data management, an administrator needs to configure the environment to ensure data moves in and out of the developed products appropriately.
At a high level, assuming governance is in place, the idea of bringing users and developers together onto a common platform seems like a good idea to me; a common platform to work on, and a common vocabulary of tools and components.
So what has Microsoft introduced to facilitate Fusion Development?
Comments in Development
Microsoft now allow comments in Power Automate and Power Apps.
In this example, developer Rakesh is building the Flow but needs input on the design, presumably from a user. By adding comments, user Yuxing can respond to help out. If you have worked on a Word proposal in Teams with your colleagues, this scenario will be familiar. Different members of the proposal team know different information and, through comments, information can be shared and applied to the proposal. Assuming we can “@” people as we do in Word, this seems like a good way to collaborate.
In this example, Alan has reached the limits of his knowledge and is having some trouble with importing data into the App. Alicia points Alan in the right direction by providing a link. In this case, Alicia is effectively coaching Alan by pointing him to resources to extend his skills. Again, a great way to use comments.
This could also work well in training lab scenarios where students add comments for the trainer to review and help them as they develop. While they are waiting for the trainer to respond, they could move onto another section of the lab tutorial. I can also see this as potentially enabling remote paired programming although where I could see this being annoying is someone using comments to stay hands-off but micro-manage the development process and being a fly who constantly needs swatting away.
Co-Authoring
The feature which I have seen the most resistance with among developers is co-authoring. This is the equivalent of the almost-real-time editing of the Teams Word proposal. Only, based on this animated gif from the Power Apps Blog, it seems there is no auto-save and changes only appear after a manual save. I can see this causing even more sync clashes than what the Word equivalent does.
The blog makes it abundantly clear this is very much an experimental feature, rather than part of a well-crafted vision for the product. Given the reaction I have seen among devs, even if it remains in the product, I do not think it will be extensively used. It reminds me of the children’s game Telephone where the to and fro of development will lead to a murky mess or of the old Google Chrome Multitask April Fool’s Joke where the promise is greater productivity but the reality is something different.
Overall Thoughts
I think the lowering of barriers between users and developers is a good thing; the more they communicate, the better the outcome, and Power Platform gives developers and users a common language to communicate with. The comments feature I see as having the potential for improving a lot of aspects of Power Platform development, both in terms of project collaboration as well as for training.
The co-authoring feature I am less enthusiastic for but, perhaps, I am missing something. Feel free to leave a comment if you see the co-authoring feature as helping, rather than hindering or whether you see it becoming useful in the future as it matures.
That CRM Blog 