The Three Core Principles of No-code Development

Principle #1: Use no-code to gather the requirements and prototype on the fly.

This first principle is about streamlining the upfront stages of the software development lifecycle that precede actual development. In traditional software projects, the requirements collection and Design Phase usually account for a big time and effort investment. Part of the reason why custom software projects take significant effort and time is because of the sheer amount of documentation that must typically be created (and reviewed) by both business and technical stakeholders, and this work is time-consuming and complex. These documents can often be fairly technical and use specialized notations to support custom development because they are meant to facilitate the translation from the original business intent down into detailed, lower-level concepts (ultimately being translated into lines of code by developers later in the software lifecycle). The sheer volume of documentation can also result in “losing the forest for the trees,” making it easy to obscure the overall understanding of the application and overlook important gaps or missed requirements.

Using the no-code tools to capture the requirements and design is inherently a more efficient and accurate process.

Also, the need to produce large amounts of documentation in traditional custom development often introduces costly defects due to translation errors. A typical custom software development lifecycle involves multiple people in each stage. It starts with a business analyst whose job is to meet with the business and document the business requirements. These requirements are then translated by a solution architect to design the overall solution and then translated again by developers to create detailed specifications. Finally, they’re translated one last time by testers who develop testing plans to ensure the software aligns with the requirements. There is a risk of introducing errors into the documents at every stage of the translation process. Errors introduced early in the process — while gathering business requirements for example — create exponential waste because each subsequent stage develops materials based on the early error. No-code development takes a very different approach. In contrast, using the no-code tools to capture the requirements and design is inherently a more efficient and accurate process. Each of the major elements of the functional specification can be described visually, such as capturing the design of user interface (UI) form layouts, business process flows, and business logic. Using no-code tools is a highly efficient way to capture the specification and facilitate a more direct and effective way to review and gather feedback from stakeholders and end users. Business stakeholders do not have to be technology literate — they can be shown working prototypes of the no-code application very early in the lifecycle, making it easy for them to understand, navigate, and provide feedback to the no-code development team. This improves the efficiency of the process and results in higher-quality feedback.

Finally, all the time spent during these no-code activities does not result in “throwaway” documentation. As you use the no-code platform to build your prototype, you are creating both a specification and a working application. This results in greater efficiency and productivity. It also means that as you change and iterate on the underlying model, the specification and app stay synchronized throughout the lifecycle. This is a huge advantage over having to maintain both the specifications and the application code and keep them updated in tandem.

Principle #2: Everything that can be developed with no-code, should be developed with no-code.

The second principle is about minimizing the complexity of your overall solution architecture by adopting a primary architecture of no-code. While there are many options available for designing your overall architecture, pursuing too many options can introduce unnecessary complexity — just because one can choose from many options does not mean that one should! Also, teams can often fall into the habit of sticking with what they already know. Companies with heavy expertise in software development tend to overuse code and apply it everywhere since it is a learned behavior that is difficult to unlearn. In contrast, a goal of the no-code approach should be to break this cycle and use coding only as needed as a part of the fusion team approach.

Betting on a no-code approach across your application gives you a more unified and streamlined architecture that will ultimately be simpler and easier to maintain.

Simplicity is good. Sometimes there is a temptation to identify many possible technical alternatives in the solution approach in the quest for completeness. However, understand that every time you introduce more options and custom code, it comes with an inherently higher cost of longer-term maintenance and support. Over time, it becomes more difficult for developers to understand the original design choices. When new developers join, it will take them longer to review the original design specifications and solution components if they’re built using multiple programming tools or languages. They’ll also need to understand more layers in the overall solution architecture. While this may have seemed advantageous to the highly trained and experienced software architect who initially designed the solution, it can make the overall updating and evolution of the app more costly and complex. There are countless technology solutions that are so complex that only the original developers fully understand. As any company with an aging workforce will tell you, losing the original knowledge of a solution sometimes prevents you from making future changes out of fear of breaking it.

Betting on a no-code approach across your application gives you a more unified and streamlined architecture that will ultimately be simpler and easier to maintain and support. New no-code creators will have a faster onboarding time as they come up to speed on the application. A no-code team will also be more self-sufficient because they are able to evolve and support the application themselves — they don’t need to worry about finding specialized skill sets or depending on IT to provide development support. This ultimately reduces the total cost of ownership and accelerates the ability to change and evolve the application.

Note: this principle should not be taken to an extreme; to mean that we recommend against any use of third-party software or custom-developed components! That is not the case, it is important to have a clear and rational decision framework for anything that is added to the solution. The most optimal tactic is to take the simplest approach possible while striving to make no-code the primary underlying architecture.

Principle #3: Deliver to end users as fast as you can.

The third and final principle is about speed — and avoiding the trap of aiming for perfection. Classic software development methodologies have often attempted to maximize end user value by stuffing as many features as possible into the first release. This is partly driven by stakeholders’ honest desire to “have it all,” but it is sometimes also driven by concerns about the timeliness of getting to the next update. If you’re concerned that the next release may take weeks or months, then you’ll push hard to sneak all you can into the first release.

In contrast, no-code does not wait for perfection all at once but instead realizes it over time. No-code aims to release features quickly to the end user — even if it is a very tight and minimal solution. The market and competition move quickly, and it’s better to release something impactful, relevant, and timely — even if it’s a highly-targeted subset of the scope — than it is to delay and try to take on a massive set of functionality all at once. In the Creatio model, this is discussed during the Design and Go-Live Phases of the lifecycle.

Also, while it’s important to deliver value to the user, it doesn’t have to be concurrently. Instead, it is better to choose the minimum possible scope that will unlock the business value, then continue to keep adding incremental features to end users quickly in small updates. This will continue to move closer to the original longer-term strategic vision with the advantage of providing more adaptability (you can evolve and course correct with every incremental step). This approach also usually results in more satisfied and engaged stakeholders as they will see the commitment to rapidly responding to feedback. Ironically, this will actually make stakeholders better at prioritization, and they will be less anxious about deferring items in the backlog as they build confidence that it will not be a long wait for the next rounds of updates.

More detailed information can be found in Creatio’s No-Code Playbook.

This blog post is part of a series of posts based on the No-Code Playbook.