Coders. Programmers. Developers. Software Engineers. These names all apply to people of varying expertise who create software. Lately, we have also added citizen developer and business developer to the list. Unlike the medical field, for instance, where someone’s title immediately gives you insight into their education and experience, the names given to software creators come with no corresponding requirements, making it difficult to determine a person’s real experience level based on title alone.
The industry has also experienced a steady acceptance of new application development technologies, some of which are expected to become major contributors to business success for decades to come. To differentiate these new solutions from traditional development practices, vendors came up with new names to describe “how” their technology works, which industry thought leaders picked up and expanded on. So, in addition to the many names we have for people who create software, we have several names for the development environments used to create software: no-code, low-code, high-code, and pro-code.
At issue, are new development technologies with capabilities, that, at minimum, equal what developers have been using for the last decade. The real differentiator now between new technologies and existing, hand-coding tools, is how they allow software creators to work, either using a visual development environment or by typing out code, or both. And though the technology has transformed to the point where there is very little difference, our reluctance to let go of yesterday’s naming conventions is holding us all back.
Maybe it’s time to let go of convention and focus on the real goal: delivering well built, amazing applications, quickly and efficiently.
Addressing the Elephant in the Room – Citizen Developers
Most IT pros agree, people holding the title of “software engineer” are the most technically advanced application creators. Most also agree, what software engineers do is considered “high” or “pro” code. Software engineers primarily hand-code, but most of them do rely on integrated development environments (IDEs) and a number of other tools–both integrated into the IDE or not–to do their jobs.
Coders, by comparison, are considered less experienced developers who also write software by hand. But while the essence of the work is the same as a software engineer’s, coders lack the years of experience needed to build complex applications.
So then if a coder is entry-level, what exactly is a citizen or business developer and why yet more names? The citizen and business-developer class was born from a need to describe a new type of software creator within organizations. They are inexperienced application creators not working for IT, but who create software solution(s) to solve specific job challenges. Usually, they are part of a specified line of business (lob).
By any definition, we can all agree citizen developers are not coders, programmers, developers, or engineers. It is widely believed the applications and tools citizen developers create are inferior to what an IT team would build or source externally simply because the creator lacks significant experience in app dev.
That’s a perfectly valid point in cases where an inexperienced application creator tries to build an application by hand coding in a language he has little experience in. But what if a citizen developer uses an integrated development environment (IDE) the same as, or better than, what IT uses? And instead of hand-coding a new application, a citizen developer uses a visual modeler based on the same languages the pros use with pre-built and tested code blocks that just need to be “dropped” into place. Is that inferior? If so, why? Is it the experience of the builder, or the capabilities of the tool the builder uses?
These are the questions troubling an industry comprising (1) veteran application developers whose salaries are largely determined by their level of experience, (2) platform vendors who believe the only way to successfully meet the growing need for software development is by reimagining the act of application development and who are trying to figure out for whom their product is best suited and (3) analyst and media professionals just trying to classify everything.
Shifting the Discussion around Citizen Developers and Traditional Developers
As an industry, we need to publicly address two things: 1. The real differences between professional developers and so-called “citizen” or “business” developers. 2. Whether “pro-code” developers can push the limits of their creativity and output using the same platform and tools as junior and citizen developers.
Addressing these questions, and acknowledging their boundaries (or lack thereof) is the only way we can move beyond the senseless notion that a particular development technology is inferior simply because someone with only moderate development experience can build applications with it.
To answer question one: Professional developers have about as much in common with citizen developers, experience-wise, as seasoned CEOs and recent college graduates. Creating a new spreadsheet to track departmental expenses does not make a person a CPA.
To answer question two, here’s another question: If a newly-created finance spreadsheet does the job, what does it matter who created it, or how?
The answers to both of these questions brings us back to the topic of new application development technologies, specifically no-code and low-code. Understanding their places in today’s development environments is critical to developers’ and businesses’ future success.
No-Code Is for Citizen Developers
You have probably seen the term no-code used interchangeably with low-code. Intermingling the two terms is a shell-game designed by no-code vendors to convince organizations their tools scale up to the enterprise level. The simplest way to confirm whether or not a particular vendor’s no-code solution will meet your enterprise needs is by looking through their Case Studies. In a vast majority of cases, no-code solutions are not scalable to the full portfolio of use-cases for the enterprise.
So let’s state something for the record: “No-code is not intended as a replacement for professional developers’ advanced integrated development environments.”
No-code, as a stand-alone technology, was never meant to replace high or pro-code development tools and practices. Anyone who tells you otherwise doesn’t have your businesses’ best interests at heart. But that doesn’t mean no-code practices and resources don’t have a place in ITs toolkit. No-code tools and capabilities can safely offer business users a way to create their own internally-useful applications, complete with great UX/UI considerations, workflows, and security, without having to engage IT in multi-month projects.
Low-Code Platforms Are Great for Professional Developers
Now that we have established when, and for whom, no-code capabilities are best suited, let’s look at low-code.
As well-intentioned as our friends at “Big Analyst Firm” are, their application of the term low-code, and the requirements a platform has to meet to qualify for inclusion in the low-code category, is partly why there is such confusion about visual development platforms.
We now have no-code platform vendors ranking poorly, but ranking still, alongside enterprise-class visual development solutions (A.k.a. “low-code”) in analyst reports. Which is really unfair to some no-code vendors, given the rigorous requirements for inclusion in the low-code category, and the need for analysts to have someone to put on the left side of the graph. After all, everyone can’t be a “leader.”
And while category vendors understand the difference between ranking in the upper-right quadrant vs the bottom-left, most skilled developers do not. Neither do many journalists covering emerging app dev technologies, leading to internet listicles like, “The Best Low-code Platforms,” where no-code-only vendors are stack-ranked alongside enterprise-class visual development platforms the analyst firms have dubbed “low-code.”
The truth is that while most visual development, low-code platforms are also no-code to some extent; the opposite is not true. No-code-only platforms’ capabilities do not “scale up” to the demands and use-cases of visual development for enterprises.
If you’re asking IT professionals to give up an IDE that’s an industry standard, and an absolute “must-have” on their resume, what you offer as a replacement needs to be more than comparable; it needs to be better. And “better than pro-code” is not a term you would apply to no-code-only tools.
However, for professional developers, enterprise visual development platforms include the same basic capabilities most of today’s advanced IDEs offer. But since their roots are based in efficiency, simplicity, and speed, everything about today’s visual development solutions is optimized to help developers create software and applications faster and, yes, better.
Most of all, these new platforms give developers choices. Though the majority of web and mobile applications today share a great deal of backend code, at some point, particularly when designing core systems, you will need to write some custom code by hand. It is at this point, professional developers argue a myth about visual development’s extensibility that is a decade old and bears no more resemblance to today’s platforms as 80s hacker movies resemble modern digital terrorists.
The argument: Low-code, enterprise-class visual development solutions aren’t extensible.
Maybe that was true a decade ago, but it’s not true anymore. If it were, Gartner wouldn’t be predicting that 65% of the app dev projects will include low-code in four years.
Everything about today’s enterprise low-code platforms are designed to work with developers tools and habits, not against them. Need to switch over to hand-coding? No problem. Want to provide multiple variants of a MVP to show a LoB executive in the same amount of time it normally takes to build one MVP? It can do that too.
Redefining the Low-Code Space (or more boldly, “The Death of Low-Code”)
In the nearly two decades since its inception, visual application development has grown from being an innovative idea to a disruptive technology. The term “low-code” is no longer sufficient as a descriptor for a development practice that is as robust as any legacy development environment, and one that is more inclusive for developers of all skill levels.
I would like to issue a challenge. Not just to analysts or the media, but also to others in the so-called “no-code” and “low-code” spaces. Over the next 12 months, let us first stop trying to sell no-code as the solution for all of ITs bottleneck problems. Let us accept that there are use-cases where no-code tools are well-suited, but let’s also recognize that enterprises are not advised to adopt a no-code solution if it is expected to facilitate anything but the creation and maintenance of business applications and workflows.
Second, let’s recognize that enterprise low-code platforms can support IT in the same capacity as traditional, pro-code, IDEs. And in doing so, let us stop using the term “low-code” to describe an evolved category of application development that goes beyond legacy solutions. If a development solution, at minimum, allows a developer to hand-code as freely as a traditional IDE, then it is at least deserved of the IDE appellation.
For all of this to happen, it will require a sea-change in how vendors market themselves, and an acceptance that, for now, maybe some vendors’ solution will appear in at least one less analyst report each year. But that is an acceptable tradeoff for giving businesses what they really need without confusing capabilities with outdated naming conventions.
Marcom Today - Portfolio site of Chris Souther 
1 comment