Why No Code rather than Low Code – It’s a culture thing, not a technology thing

I’m noticing a bit of a fight between No Code (e.g. Betty Blocks) and Low Code (e.g. Outsystems or Mendix) approaches to generating business outcomes. No Code is for the Citizen Developer; so is Low Code; but, in practice, Low Code often seems to live in the domain of the Professional Developer. I think these distinctions matter, because No Code is more disruptive to the status quo than Low Code; and perhaps that is what we will need as we move to Mutable Businesses in constant evolution.

I have been an enthusiast for automating the coding of applications since the mid 1980s, when I first met tools like Uniface and IBM’s Application Development Facility II, which showed that high-level business-oriented approaches were feasible, for general businesses. I saw it as another step in abstraction as we moved from machine/code and assembler (which I first coded in) to 3GL and 4GL and beyond. Then C++ appeared and we returned to Assembler…

Computers didn’t really have the power to fully automate application generation back then (unless you had a mainframe) but I still think that the main issues were cultural, not technical. The silo’d IT group had more power than the Business, it liked coding, it liked job protection and if the Business found a generator which promised to fix its application backlog problems, it could always be told “we know best, C++ is more maintainable and faster, your generator will run out of steam and you’ll be building unmaintainable ‘legacy’”… But, the business still saw an application backlog, and unmaintainable systems and applications which didn’t do quite what the business needed. And it saw the IT group building “new legacy” in Visual Basic …

In the 21st century, things have moved on a bit. Business managers have studied IT at school and college, and can ask intelligent questions when told “the computer says NO”. DevOps is helping to break down silos, although often more between Dev and Ops than between Design and Business (a possible DevOps antipattern is delivering the wrong software faster and more efficiently). In the meantime, we still have an application backlog, we still have application failures caused by bad, unprofessional, coding (the WhatsApp debacle was caused by a buffer overflow, presumably written by a “highly skilled” coder, and easily prevented using any number of automation tools) and the silo walls  between IT and business, while lower, are still there.

There is even good news on the automated generation of applications. Outsystems, Uniface, Mendix and others can point to successful use cases in serious business applications and they often achieve the promised productivity from automating application generation. But, they are far from ubiquitous, code (with all its productivity and reliability issues) is still popular, and Lo-Code products like OutSystems and Mendix still fundamentally support code “for the difficult bits”. They work, they are very productive (especially for application projects that are failing with more conventional methods) but they accept the inevitability of hand-crafted code somewhere in the system. They are a huge improvement on what came before (so why isn’t everyone adopting them?) but I don’t see them displacing code entirely, so I’m not sure I see them as supporting the Mutable Business in its constant state of evolution as effectively as they need to. We still have too much control by an IT silo, so we still have application backlogs and “under the radar” grey IT.

Then, along comes Betty Blocks, with an unashamedly NO CODE approach, centred on the Citizen Developer, working with the IT group purely as professional mentors. The Business is firmly in control and running the show. I’ve now spent several hours with Chris Obdam, CEO of Betty Blocks and I think I’ve got a handle on what it brings that is different. This isn’t really the Technology. The Betty Blocks technology approach seems not dissimilar to that of Mendix (both originate in the Netherlands), they would say done better, and is based on interpretation and clever cache management, although one would have to dig deeper for a real technical comparison.

I think that what makes Betty Blocks really different, however, is its unashamedly No Code culture. This implies that control of application development and delivery lies entirely with the business, which will make it more effectively responsive to the needs of the Mutable Business but which also has implications:

• The business needs a management structure that doesn’t include an IT group silo under another name;
• It needs an effective hands-on. business-oriented Architecture capability – one that doesn’t reside in an ivory tower – to pull the Citizen Developer community together;
• It needs developer-like skills for the “craft” of building applications – possibly, there is a role for the old IT group as “technology mentors” (if it can find the necessary people skills);
• It needs an effective business-focused training facility for the Citizen Developers – professional applications have to be built properly;
• It needs a light-touch “just enough” governance regime – “no surprises” for citizen developers who must devote their time and effort to business outcomes;
• It needs to manage very considerable cultural change, if it is to reach Citizen Developer nirvana without losing “corporate memory” or impacting service levels to the current customers who are, in effect, paying for the change process and might go elsewhere.

So, what next? Well, this sounds like a Right Automation initiative, and I’d love to take part in a discussion with practitioners actually involved in working towards such a thing. Do they recognise my potential issues, have I missed any, and how do we address them?