Editorial
The line keeps blurring between developer experiences that emphasize high-code implementations on the one hand and design and marketing platforms — also known as citizen-development platforms — that aim to democratize web development by providing no-code and low-code solutions to the problem of building websites on the other. As the coronavirus pandemic continues to scramble all the calculations that went into vendor selection by marketing and developer teams alike, it seems that the two extremes of the spectrum — no-code and high-code — are getting harder and harder to reconcile.
In a sense, the current popularity of no-code and low-code development platforms hearken back to the late 1990s and early 2000s, when what-you-see-is-what-you-get (WYSIWYG) website builders like Dreamweaver and FrontPage were in full swing. But here’s the question too few no-code and low-code customers are asking their technical teams and the vendors they increasingly rely on: What does the code produced look like, and how do we manage it? What does the long-term maintenance story look like? What happens to the end result of a no-code tool when the no-code vendor vanishes?
After all, many web developers have horror stories about times they were handed FrontPage or Dreamweaver implementations only to open the code and realize the coming maintenance burden. No-code and low-code vendors remain clustered at the lower end of the market, but they increasingly have their eyes set on the cross-functional teams that make up the enterprise segment of the market. In my view, however, such cross-functional teams would be better served by bridging the yawning gap between no-code and high-code solutions with what I call flex-code.
Low-Code and No-Code Don’t Work for Cross-Functional Teams
In my previous op-ed for CMSWire, I shared how the content management system (CMS) occupies a unique niche in the larger ecosystem of software due to its unicorn status as a cross-functional tool that straddles personas. The CMS has, over the course of the past few decades, become a compelling collaboration center for editors, marketers, developers, stakeholders and copywriters. It’s always been cross-functional and multi-persona.
If we look at the growing popularity of no-code solutions, particularly among CMS customers, however, an alternate reality begins to take shape. Content implementations, particularly those that involve multiple channels for content delivery, are notoriously difficult and require juggling multiple sets of requirements from stakeholders with wildly disparate needs. So why do we keep pigeonholing large content implementations into ill-fitting approaches like no-code and low-code tools?
In defining the new “marketing maker,” Scott Brinker explains on ChiefMarTec.com that the new emergence of no-code tools focuses on three aspects of web and mobile development: design and content (the user interface), spreadsheets (data) and automation (logic). There’s only one problem: All three of these things require complex integrations that low-code and no-code tools routinely paper over without acknowledging the many risks inherent to those integrations.
The result is a brittle architecture that can’t be fully managed by marketers far down the road, and worse, no developer wants to touch with a six-foot pole. For cross-functional teams, especially those that are evenly split between editorial and development responsibilities, it makes little sense to adopt low- or no-code tools even as part of a larger content implementation. After all, any low-code or no-code purchase results in vendor lock-in and a developer experience that might not be up to snuff for the long-term maintenance of your architecture.
Related Article: DXP? Web CMS? Content Services Platform? Navigating the Chaos of Vendor Categories
Low-Code Locks in Developers. High-Code Locks in Marketers
The calculus can be challenging for many organizations: Either you lock in designers and marketers into a tool they are forced to use until the end of time, or you obligate unwilling developers to work with code or development environments that bear no resemblance to their preferred workflows.
Developers have made no secret of their distaste for low-code development platforms, because they tarnish the developer experience. For instance, some low-code tools can only handle data in comma-separated values (CSV), despite the fact that most developers today prefer to create and consume data in JSON (or even XML) over CSV. Without developers being involved in any selection of a no-code or low-code tool, such integration issues could be swept under the rug until it’s too late to correct course.
Ironically, contributing editor Isaac Sacolick recommends in InfoWorld that “low-code, no-code, and citizen-development platforms have a place — but they need the guidance and oversight of professional IT developers to really deliver.” What exactly was the point of adopting Webflow or Airtable in the first place, then? Few developers, like the FrontPage and Dreamweaver inheritors of old, have the patience or willingness to work with the gobbledygook that invariably emerges from low-code WYSIWYG tools.
At the same time, however, developers would be loath to ignore the complaints of designers and marketers that have fled en masse to the low-code paradigm, particularly among small- and medium-sized businesses that have always preferred easy to use design tools like Wix or Squarespace. But questions remain for developers who will need to inherit this code in the event the vendor goes bust or the architecture needs to change.
Learning Opportunities
Webinar
May
30
ChatGPT and the Future of Conversational AI
This discussion explores various aspects of AI implementation, ethical considerations, and challenges for your organization.
Webinar
May
31
The Evolution of Employee Listening - 2023 Trends & Best Practices
Learn proven effective methods and solutions to supporting an inspirational future of Employee Voice
Webinar
Jun
1
How organizations can design, build and run Generative AI into the Customer Experience
Discover how to drive enhanced CX through Generative AI
Webinar
Jun
6
The Future of Social Media: Emerging Trends and How to Stay Ahead of the Curve
The impact of emerging technologies like AI on social media
Webinar
Jun
7
The Building Blocks of Personalization
This webinar will explore how personalization can create powerful ecommerce shopping experience.
Webinar
Jun
13
The Future of Contact Centers with AI at the Helm
Learn how to balance human intuition and interaction with the potential uses of AI to create delightful and lasting CX
Webinar
May
30
ChatGPT and the Future of Conversational AI
This discussion explores various aspects of AI implementation, ethical considerations, and challenges for your organization.
Webinar
May
31
The Evolution of Employee Listening - 2023 Trends & Best Practices
Learn proven effective methods and solutions to supporting an inspirational future of Employee Voice
How high-quality, truly, is the code that is produced over the hedge, and how future-proof is it? Will it hold up to potential security vulnerabilities, and how will it adapt to evolving content architectures, especially in light of JAMstack’s growing adoption? What happens when the design system needs to change but its underlying technical foundation is no longer supported? What happens when we need to add in content delivery channels like mixed reality or digital signage that remain largely developer-driven?
Related Article: Is Low-Code Technology Right for You?
Flex-Code Is What Cross-Functional Teams Need
Just like content management as a whole, cross-functional teams need the sort of deep collaboration and enablement that allow both developers and marketers to engage with their digital experiences at their preferred level. Our CMS implementations have long mirrored this unique combination of use cases: Developers build themes that reflect the designs they’ve been given, but they also stop at a certain tipping point and let site builders and designers pick up where they left off with layout management on a per-page basis.
What we need is flex-code: the same kind of cross-functionality that exists in CMS implementations of old that makes all users happy without sacrificing a project’s long-term viability. Flex-code means incremental innovation: passing a baton rather than polishing an end product that stays static forever.
A flex-code project is about oscillating between low-code and high-code as needed for the requirements of the team at that moment. It could go something like this: Once an ideal underlying design system is in place, based on a style guide, developers pass the baton back to the marketing team by “injecting” the code back into a low-code tool. Then, once designers have based a site design on that design system, they “eject” the code out of the low-code tool back into a high-code format that developers can easily interact with, with the site design reflecting the development approach the technical team has chosen.
Once development is complete, developers can then “eject” their code back into a low-code tool that designers and marketers can manipulate. And whenever integrations — the most brittle and unmaintainable aspects of any low-code project — need to be updated at a lower level than low-code tools make possible, marketers can “inject” the code back into a high-code form for developers to do the heavy lifting in updating the integrations. At each stage, there’s an opportunity to polish; designers and developers can handle any regressions in design and code, respectively, as they pick up the baton.
The issue with flex-code today, of course, is there isn't a single tool in existence that can handle both low-code and high-code concerns gracefully. Today, we’re stuck between design tools that go part of the way in furnishing what developers need — like Avocode and Figma — and development tools that are far too complicated and code-heavy for marketing teams to even begin to interact with. Ironically, many CMSs were in fact flex-code back in the day, demonstrating the sort of baton handoffs and incremental innovation that cross-functional teams crave.
Though some promising steps are emerging from popular technologies, and though such a paradigm would lead to more resilient implementations, it’s easier said than done. That doesn’t mean we should permit brittle implementations when the complexity of content in a new omnichannel landscape has never been more challenging — or more exciting.
Learn how you can join our contributor community.
