10 Low-Code Rules for Serious Coders

November 21, 2022

Blog

After the grueling stress test of a global pandemic, corporations must now contend with the stresses of a war and a weakening macroeconomic environment and yet transform to become modern, composable, and competitive enterprises. Technology executives at the center of this transformation are pursuing bold yet pragmatic strategies, including building and scaling new software-driven business capabilities quickly. For them, the holy grail seems to be democratizing software application development itself – with low-code/no-code (LCNC) approaches – to deliver at speed and at scale to the business.

Professional developers and enterprise architects getting involved in governing LCNC development as enterprises become deliberate about policies, processes, and people to scale this movement responsibly. But pro coders themselves are not yet active adopters of LCNC platforms – they range from interested observers (at best) to those that detest LCNC platforms (for their valid reasons).

Based on industry estimates, around 35-40% of a pro coder’s time is spent in setting up, creating guardrails, importing, and integrating with data sources, writing code from scratch, making code secure, testing and retesting applications, managing source control and versioning, adding internationalization, making them accessible, optimizing for performance, and maintaining or upgrading applications. Another 30% of the time is spent on non-technical or operational activities.  That leaves less than half of their productive time for thinking, innovating, and crafting complex and compelling apps and experiences.

Clearly, pro coders experience pain. So, what should low-code platforms offer to entice pro coders to adopt and, better yet, embrace them? Let’s dig in.

Rule 1: Be Open. Provide Familiarity and Visibility

What if a low-code platform used an open standards-based, popular tech stack (React, Angular, and Bootstrap for UI; Spring for backend; Docker containers)? What if developers could actually see and read real (not model-generated or metadata driven) code being generated? What if this code was written the way they code?

Pro coders are accustomed to seeing, reading, and understanding real code in a language or framework that is open and widely accepted. So, just give it to them.

Rule 2: Custom Everything

Developers need the ability to add fine-grained logic to their applications; that is, writing custom services or creating custom APIs in a code editor alongside the drag-and-drop canvas. 

Low-code platforms should offer developers the ability to configure each out-of-the-box widget to a high degree to allow for creating visually captivating experiences.

Imagine if developers could go beyond a standard UI widget library and create their own custom components – building blocks of API-infused UI – and add to their private library. Sometimes, developers may also need to import pre-built components (React or Angular or GraphQL components exported as standard Web Components) into their low-code development platform and reuse them. 

Finally, developers may want to create their own application theme – a combination of fonts, layouts, colors, and styles – to create a differentiated yet consistent branded user experience across one or more applications or products.

Rule 3: Integrate Easily with Data Sources. Set Up Quickly.

Integration to and extraction from data sources such as APIs (REST, SOAP, or WebSocket), databases (such as MySQL, Maria DB, PostgreSQL, Oracle DB, SQL Server, IBM DB2, Amazon Redshift, SAP Hana, HSQL, and Mongo DB) or streaming data sources (like Kafka embedded in the app) – must be supported and be effortless. 

CRUD operations are usually hardcoded by the developer and take up a lot of time. If a low-code platform could automatically generate all the CRUD APIs once the data source is imported, it cuts down the development time immensely. Similarly, an editable abstraction of the database that replicates the schema of the DB can help developers manipulate the data from within the platform itself.

Once imported, developers should be able to bind their UI easily and quickly to the backend via passing variables. Data from a REST call should then be easily displayed as entities on a page without any workarounds or wordy importing and model-definition. Likewise, with a Swagger import, descriptions should be able to handle reusing the same model in multiple endpoints or recursive models.

Rule 4: Apps Must Be Secure, Scalable, and Performant

For user authentication, developers may need to integrate with database, LDAP, Active Directory, SAML, and other authentication providers. SSO should be easily enabled with support for SAML federation and Central Authentication Server (CAS). For authorization, low-code platforms need to support coarse as well as fine-grained permissions that extend across pages, individual widgets on a page, and even individual APIs exposed by the application. 

Developers look for protection against OWASP vulnerabilities (XSS, CSRF, brute force attacks, SQL injection) and support of encryption standards such as TLS 1.2+ during app hosting. Ideally, low-code platforms need to be certified by security leaders like Veracode who perform rigorous static and dynamic tests (iAST, SAST, DAST, and SCA).

Through session-less architecture, distributed caching, horizontal scaling through containers, and UI framework-specific performance features (for example, Angular 13 has lazy loading, Brotli compression, tree shaking, Ivy), developers using low-code platforms can build highly performant apps, minimizing chattiness and UI-to-backend roundtrips. As an example, instead of storing state in a session, it can be backed by a distributed cache (such as Redis) to allow apps to scale horizontally. 

Rule 5: Deploy Anywhere, Anyhow

Developers cannot be constrained to a vendor-specific app deployment infrastructure. They need the freedom and flexibility to host their apps anywhere – on any public, private, or hybrid Cloud, on K8s clusters, or on bare metal/on-premise infrastructure. Low-code platforms that offer a development model where the UI is decoupled from the backend, can allow UI and backend artifacts to be separately packaged and deployed (UI to CDN; as example, backend to a standard Java server like Tomcat) using a standard archive or a Docker image.

Rule 6: Complex and Long-Lived Apps & Large Scale Platforms

Developers hand-code some of the most complex apps and systems in use today. They need low code platforms to step up to the plate and deliver equally complex apps that can be sustainable over the long-term in terms of maintenance and enhancements. 

For example, low-code platforms need to integrate with 3rd party BPM tools (Camunda, jBPM, Flowable, Activity) that help developers orchestrate detailed workflows/tasks and need to support a full 2-way data exchange with the BPM tool’s runtime engine. Within low-code platforms, developers will expect to easily manipulate complex data (pick a certain number of arrays and use logic to combine them into a new set of arrays) and easily represent complex graphs without custom styling/CSS or tangling with data formats.

Developers may need to conditionally retrieve data using a parent-child relationship, be able to  localize and internationalize applications, handle complex core code merges and upgrades with  customized apps in deployment, deal with Swagger changes pushed to already imported Swagger  files without rewiring all the variables, write and support complex business logic interleaved with visual development, support multiple app themes at runtime, support apps as deep links, set click targets to measure/launch intents or URLs, and so on.

Rule 7: No Vendor Lock-In, Restrictions, or Fine Print

Lock-in is a strict no for developers who value independence and freedom. That starts with access to generated code. Low-code platforms that do well in this space readily offer developers the ability to not only see and read generated code, but also to export source code outside of the platform to an IDE of their choice. 

Developers also don’t like low-code platforms that force them to use their runtime environment to deploy their apps, effectively locking developers and their employers into the platform through the app’s lifecycle. Lastly, from a licensing perspective, low-code platforms that restrict developers to a limited number of apps, app objects, or end users effectively throttle developers to a commercial model that becomes quickly expensive with usage and more apps.

Rule 8: Modern (Cloud-Native) Environments, Practices, and Standards

Developers using cloud-native low-code platforms benefit in terms of collaboration, ease of access, availability, flexibility, security, frequent and easy upgrades, horizontal scaling, and the overall unit economics of the model for their app development and deployment. 

Developer-friendly low-code platforms generate code using modern design patterns (for example, a Java maven project) enabling developers to see, extend, and customize code across all layers of the application stack. They enable every user to have a workspace running as a container instance. When an app is built, a repo is automatically created for it in the low-code platform’s source control/Git (and integrated with Prometheus/EFK for logs and metrics).

Finally, developers appreciate low-code platforms that embrace modern standards, say Android Material Design specification for visual design and building interaction across multiple devices using out-of-the-box widgets and themes. They value the ability to create functional, distributable, reusable, API-integrated, and independently testable experience components. Low-code platforms that offer twelve-factor standards assure developers that their apps are trustworthy. 

Rule 9: Play Well with Design, Build, Test, and Release Processes and Toolsets

Developers using low-code platforms will want their apps to connect to, integrate with, or be embedded in other hand-coded apps. Beyond iFrame support, low-code platforms that support embedding via a micro frontend approach (such as Single SPA) offer sophisticated functionality for developers to create seamless end-to-end experiences that cover high-code and low-code developed apps.

Professional application development teams tend to use design tools like Figma, Sketch, or UXPin; QA tools like Selenium, Protractor, or Karma for testing web apps; Appium for testing mobile apps; and performance testing tools and app profilers like AppDynamics or New Relic. DevOps teams have a plethora of tools for the build, test, integration, and deployment processes. Post-deployment, developers would like to monitor app performance events, and page tracking via Google Analytics or Adobe Analytics. Low-code platforms that endear themselves to developers will have to play well and integrate seamlessly with these toolsets and design, build, test, release, and monitoring processes.  

Lastly, while low-code platforms may provide their own VCS (such as Gitlab), they need to offer easy integration with external repositories like GitHub or Bitbucket. Developers should be able to pull, view, and push changes and merge conflicts between source control systems. They will appreciate low-code platforms that support app versioning from code-level commits to component-level and application-level versioning for releases (including a major or minor version format), allowing multiple versions of the app to co-exist in different deployment environments such as test, stage, or pre-production. 

Rule 10: Future-Proof Me, My Apps, and My Employer 

A UI developer or backend developer using low-code platforms should be able to develop a complete application with, for example, a basic knowledge of SQL, JS/Java, and zero DevOps, and transform to full-stack developers. Using the Java world as an example, developers don’t need knowledge of advanced JS framework, HTML5, CSS, Bootstrap, Spring, ORM, REST, advanced SQL, native device programming, mobile integration, building and running Docker scripts, or manual integration with CI/CD pipelines.

For technology stack upgrades for apps built using a low-code platform, developers should be able to open apps in the target version of a low-code platform with the latest tech stack (as an example, Angular 14 for UI). The app upgrade should be automatic, and the transition seamless.  

Developers and CTOs/CIOs alike are constantly worrying about creating technical debt for the future. Enterprise-friendly low-code platforms are built on an open-standards based modern tech stack, shift the burden of tech upgrades to the platform, offer source code that is extensible outside of the platform using commonly available skillsets, and play well with a modern enterprise’s toolsets, practices, and standards.