03
Principles of No-code Development
“The things best to know are first principles and causes, but these things are perhaps the most difficult for men to grasp, for they are farthest removed from the senses”
We’ll cover a lot of ground in this Playbook and make sure you understand no-code strategies, how to organize for success, what methodologies to follow, etc. However, before we get into these details, let’s step back and examine the “first principles” of no-code development. First principles are essential and, as observed by Aristotle, they are sometimes the most difficult concepts to grasp. It’s easy for the busy reader of this Playbook to get so immersed in the “how” of no-code that we forget to first understand the “why.” So, we are going to begin with a discussion of 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.
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 of 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 the 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 fall often into the behavior of sticking with what they already know. Companies with heavy expertise in software development tend to overuse code and apply it everywhere as it's a learned behavior that is difficult to unlearn. In contrast, the 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.
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 trained 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 the solution. 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. Your 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 your ability to change and evolve the application.
Note: this principle should not be taken to an extreme to mean that we are recommending against any use of third-party software or custom-developed components! That is not the case, it’s just important to have a clear and rational decision framework for anything that is added to the solution. We’ll present such a framework later in Chapter 8 when we discuss the Options Analysis stage of the methodology, which helps guide your selections based on your requirements. We’re recommending that you take the simplest approach possible by 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. This will be 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 done all at once. Instead, 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 you 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 your commitment to rapidly responding to feedback. Ironically, this will make stakeholders better at prioritization as well as 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. This approach is referred to as “Everyday Delivery” and will be further outlined in the Playbook.
Final Takeaways
It’s critical to understand the principles of no-code development and embrace them to shape the way you approach development activities. These principles have inspired and shaped the no-code methodology that we will explain throughout the Playbook. Take time to internalize them before launching into the rest of the no-code development.
No-code development requires thinking differently about the roles and personas that are part of the process. Let’s dive in and explore what a no-code team looks like.
