Get Over Your Low-Code Prejudices to Pay Down Your Technical Debt – InApps 2022

Any culture inevitably develops an internal classification system reflecting perceived status and associated worth within its ranks, and developer culture is no different. The ridiculous virtual chest-thumping of the “code-hard, code often” brogramming ethos that has flourished alongside the growth of connected application development is an obvious example of how this process manifests, but it comes in subtler forms as well. For example, what IDE do you enjoy using the most? Sure, you may be a fan of IntelliJ or Visual Studio — both excellent environments — but real coders use a text editor like TextMate or Atom, right? Unless you’re really hardcore and use EMACs. Or you’re really, really hardcore and use only vi.

At the end of the day, what matters most is getting the job done well and on time, but many of us just can’t help ourselves when it comes to strutting our stuff in front of our peers. In this context, the very idea of adopting something that would require us to do less actual coding — or, providence forbid, no coding — is just anathema to how many of us identify as developers.

But that attitude runs counter to another issue that affects every developer — technical debt. You can call it a backlog or legacy code or whatever you want, but the truth is that every developer expected to write production-level code is under constant time and resource constraints to deliver, leading to difficult decisions about what can and can’t be done. We want to do it all, but real-world pressures demand something must be sacrificed. In especially dysfunctional teams, this can create a “Culture of No,” best exemplified in the oft-heard tradeoff, “No, we can’t add that feature, unless you’re willing to kill this other feature of equal or greater value.”

New ways to quickly deliver business applications are needed, and this is where low-code and no-code systems can shine. For developers, they provide a handy tool well-suited to particular tasks. Teams can shrink the build-test-deploy cycle by leveraging the limitations inherent in a low-code environment, which can keep a developer’s focus trained squarely on the task at hand. You don’t see carpenters bemoaning the use of nail guns just because they know how to wield a hammer — developers should view low-code setups in the same light. You might not use a low-code development tool to build your core content management application, but it can save time when used to design the content approval process that the application relies on.

There’s also an inclusive element to low-code tools that ultimately benefits overtaxed dev teams. Low-code environments can allow non-developers to design their own interactions with minimal effort or experience required. This brings app development for specific business processes closer to the subject matter experts who know them best. Using the previous example, the developers of a content management system would direct all their skill and attention on the core pieces that allow for the content to be created, stored, and distributed, but they could off-load the construction of the content approval process to the business team responsible for enforcing it. Handing over the reins for controlling those flows allows the business team to build exactly what they need without waiting for developer time to free up.

Low-code and no-code environments are not replacements for a solid internal development team, but they can provide a means to take better advantage of the services developers produce. This creates yet another incentive to expose every service as a fully decoupled web API so they can be picked up not only by application developers, but by business experts using them in their own interactions.

Low-code and no-code solutions deserve a spot in the developer toolbox. They can help organizations overcome technical debt and free up time to focus on what matters — positive benefits that pose no threat to developer identity. It’s time you give these systems another look.

Feature image via Pixabay.