Technical Debt - The promise and peril of low-code applications
Episode 14
Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now, instead of using a better approach that would take longer. Technical debt is repaid by spending development time on refactoring the project at the cost of adding new features or functionality. Technical debt can be viewed similarly to financial debt, if not repaid it will accrue interest, making future repayment more difficult.
Technical debt is an inescapable phenomenon of our modern digital age. As technological progress increases, the time a solution spends in development shrinks. Development principles like Agile and DevOps advocate for continuous deployment and integration of working products; deliver value as fast as possible. Striving to have production code in the hands of a user as soon as possible is a situation that is ripe for generating technical debt. There is great temptation to cut corners to meet the release schedule. With business staff (not developers) now driving the development process, low-code applications add another dimension of complexity. Low-code platforms promise high productivity that empowers everyone in the organization to achieve more. But is there a hidden cost to such a powerful set of tools?
A distinction must be made while we discuss low-code applications, they should not be viewed as Shadow IT. We are going to assume that low-code applications have oversight by the organization’s IT department or technology partner. Without this structure, it is highly likely that productivity gains will evaporate as systems lacking coordination fragment. There is a trend toward having the leanest technical stack possible. Taking “lean” ideas from the manufacturing and supply chain worlds and applying them to IT infrastructure and processes. A “lean” IT system will have only the resources it needs, be responsive to changing requirements, and be resilient to shocks. These principles applied in the wild manifest themselves as API focused integrations, business analyst led development, and limited use of enterprise applications. While powerful, enterprise systems can be technical debt traps.
The promise of placing development in the hands of those closest to the problems removes several links of communication where information can be misinterpreted. Lets look at Microsoft’s Power Platform as an example. We have Flow, Power Apps, and Power BI giving non-developers the power to automate workflows, build custom apps, and drive data insights throughout their organizations. Additionally, these applications are supported by rich marketplaces with templates, service add-ons, and community discussion groups. When one can build a custom application in hours, the pace of iteration explodes, allowing for quick failures and rapid discovery of effective solutions.
But is there a cost to all this power? If business users are empowered to build their own tools and can build them rapidly, we are trading one form of technical debt for another. Take for instance traffic: if we improve roads, we do not get better traffic conditions, we get more cars. By empowering business users to build applications, we do not solve technical debt challenges, we get more applications.
Rapid iteration is invaluable. When success is found, it is natural for organizations to formalize the solution. Low-code applications developed internally, will likely be lacking documentation, have weak quality assurance processes, and often have only one individual with working knowledge of the application’s architecture. Envision a large multinational organization with many similar regional offices, where users all independently start creating solutions. Which success should be adopted globally? Who decides what to use? Should each office maintain their own solutions? How does the company support thousands of similar applications?
Power tools carry large responsibilities. At MERAK, we think it is best to see low-code applications as credit cards. The rapid iteration with inclusion of business users is instant gratification at the expense of future technical debt payments as organizations take discoveries and build the proper infrastructure to support the solution going forward. Prudent organizations will recognize this relationship and strategically accumulate technical debt, understanding that the creative ecosystem enabled by low-code development platforms can produce core products better aligned with internal needs and client needs followed by technical debt payments.