Discover how low-code platforms like Microsoft’s Power Platform empower users to create and deploy apps easily with minimal barriers, streamlining the development process for everyone.
However, as more apps are created, questions arise: who will support these applications, and who will handle updates for feature requests or bug fixes?
Many low-code applications are typically developed by a single individual, creating a single point of failure.
Despite the advertised simplicity of low-code, don’t be misled into believing that anyone can easily edit the app, fix issues, or add new features. Low-code solutions can still harbor complexities, and these can pose significant challenges for organizations and teams relying on dozens, if not hundreds, of other low- or no-code dependencies.
This doesn’t imply that organizations should heavily restrict who can create these applications, as it would defeat the purpose of low-code. The model empowers stakeholders to rapidly prototype ideas and develop low-cost solutions to challenges that traditional development might otherwise make costly.
In the low-code landscape, both organizations and developers need a strategy. Developers, in particular, should have a plan for transferring knowledge about their products, whether they are working as part of a team or independently.
How to Manage and Reduce Complexity
Our relatively small team has developed numerous low-code solutions, primarily using Microsoft’s suite of products. These range from simple low-code canvas apps to more complex solutions with hundreds of dependencies.
We’ve learned, often through challenging experiences, the crucial importance of ensuring maintainability in our development process. This involves not only supporting the applications we create but also enabling both existing and new team members to support them effectively in the future.
Initially, the allure of quickly solving problems with low-code products was compelling. However, we soon faced a new challenge: how to manage and support this diverse array of products, ensuring that both current and future team members could effectively contribute.
Take Time to Accelerate Progress
Although it may seem contrary to the low-code paradigm, taking regular pauses to evaluate the long-term impacts of your decisions is crucial. This practice helps ensure that the tools you build today remain supportable in the future.
This doesn’t mean reverting to the slower pace of traditional software development, but rather, it’s important to view building low-code products not as a race to the finish line.
Pair Programming
Incorporating traditional software development practices can greatly enhance the low-code movement. Even when applications involve minimal conventional coding, concepts like pair programming can be effectively applied to low-code product development.
Take building a Power App as an example. While traditional limitations allowed only one person to edit an app at a time, the ability for multiple people to edit simultaneously highlights the importance of a structured collaborative process.
Our team often uses a “driver-navigator” approach, where one member takes the lead in development while another provides real-time feedback and suggestions. This method keeps everyone engaged and helps prevent tunnel vision, which is particularly valuable for complex aspects of the application.
For simpler tasks, we often work in parallel but remain closely connected via Teams or Zoom to coordinate and ensure all components integrate smoothly into a cohesive whole.
Application/Code Reviews
Low-code doesn’t mean no code. Creating robust applications solely with drag-and-drop tools can be challenging. Even platforms like Power Apps include their own language, Power FX.
Allocate time each week to review or walk through others’ applications to become familiar with their work. Look for areas of improvement and be open to receiving feedback on your own creations as well.
For projects involving traditional code, this can be managed through pull requests (PRs). For purely low-code implementations, maintain a document of changes and implement a sign-off process to ensure new changes are reviewed by team members.
For instance, if you add a new screen to a Canvas app that allows users to update personal settings, document this change as unreviewed until at least one other team member has reviewed and approved it.
Involve Other Team Members
In a team setting, each product should involve at least two people to prevent single points of failure. Designate a primary and a secondary developer or product owner for each product. For larger teams, consider rotating the secondary role to ensure each member gains familiarity with the team’s products.
To engage others and facilitate knowledge transfer, have team members take on tasks such as adding new features or fixing bugs under the guidance of the primary developer. This approach fosters a sense of ownership and increases engagement with the products.
Moreover, distributing the workload more evenly reduces bottlenecks, leading to faster bug fixes and product enhancements.
When a Hands-On Approach Isn’t Feasible
Much of the above advice aims to encourage team involvement with projects. The more we engage with these projects, the better our understanding will be.
However, when hands-on involvement isn’t feasible, it’s crucial to have practices in place to address the challenges of isolated development, where work is done by just one or a few individuals.
Two key strategies to mitigate these challenges are to create and maintain thorough documentation for our products and to adhere to standard practices whenever possible. Let’s start by discussing the importance of documentation.
Document, Document, Document
As you may have observed, the low-code movement enables rapid application creation, which can lead to a proliferation of applications and fewer interactions with older ones. While these touchpoints are essential for knowledge transfer, relying on them alone is insufficient.
Whether you’re working on a team or as a solo developer, comprehensive documentation of each aspect of your products is crucial. For smaller projects, a simple text document may suffice. For larger projects, a SharePoint site could be more appropriate. As projects become more complex, dependencies such as Git repositories might also need their own documentation.
For example, consider documenting a product like a conference room reservation application. This app might include:
- User Interface: A Canvas app for users to reserve conference rooms.
- Custom Code: Code that sends a reminder email to users a day before their reservation and encourages them to cancel if the meeting is no longer happening.
- Reporting: A feature for administrators to view and analyse conference room utilisation over time to assess demand.
Thorough documentation ensures that all aspects of the product are well understood and can be effectively managed by anyone involved.
Here is how you might document this project
Establish a single source of truth for the project, such as a SharePoint page.
This page should include:
- Project Overview: A brief description of the project.
- Key Personnel: Information about the product owners and lead developers.
- Project Components: An overview of the project’s components, such as the Canvas app, custom code, and reporting dashboard.
- Special Considerations: Documentation of any easily overlooked aspects or non-standard implementations (which will be discussed further in the section on standardisation).
The SharePoint page provides a high-level overview of the project and guides you in the right direction. For individual components, the Canvas app should include comments and notes in the version history, while custom code should use Git and often feature a detailed README file.
While documentation can be challenging, it is essential. It should be thorough but also complement the hands-on knowledge transfer techniques mentioned earlier.
Standardise as Much as Possible
Whether you’re working with low-code or traditional development, establishing standard practices is crucial. This becomes even more important with low-code due to the rapid development pace, which can easily lead to disorganisation.
Develop and implement standard practices for all phases of the project, including planning, design, development, testing, and cross-training team members.
Standardisation should not replace the need for cross-training and documentation but should complement these processes and help minimise the time required for them.
By approaching problems with a consistent method, you can focus more on addressing non-standard and easily overlooked aspects of your projects.
Here are some questions to guide your standardisation process.
- What are the major steps required for each application, and who will be involved in these steps?
- What tools will you use for development? (e.g., Power Apps, Appian, Pega)
- Can you support traditional development alongside low-code? If so, what will this process look like?
- What is your overall approach to development? For example, should you design the user interface or business logic first? What database will you use? (e.g., SharePoint, Dataverse)
- What conventions will you follow in your code? (e.g., naming conventions for screens and variables)
- What does the knowledge transfer or cross-training process entail? Do you have regular times each week to review each other’s work?
Certainly, this list is not exhaustive. As you gain more experience, you’ll identify additional areas that need to be addressed. Start by developing a Standard Operating Procedure (SOP), and be ready to revise it frequently as your understanding and practices evolve.
What to Do as a Solo Developer
As a solo developer, it might seem like the recommendations above don’t apply to you, but that’s not the case. Establishing and maintaining a knowledge-transfer framework is even more crucial when working alone. While co-developing and pair programming may not be directly applicable, the underlying concepts are still relevant.
For instance, make an effort to connect with other developers and seek feedback. This can be a great way to network and gain new insights. Additionally, with AI playing a significant role in programming, you can utilise AI tools to learn new techniques and enhance your projects.
Lastly, documentation and standard practices are essential for solo developers as well. They provide a reference for future work and serve as a guide for solving development challenges independently.
Conclusion
While low-code platforms provide remarkable speed and flexibility, they can also present maintenance challenges. Rapid development, if not carefully managed, may result in issues that jeopardise the long-term success of your applications.
By deliberately slowing down and implementing a clear knowledge transfer plan, you can protect the future of your essential products. This approach ensures that your applications remain supported and sustainable, both now and in the years ahead.
Stay tuned for more valuable insights and content.
