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

Written By:
Content Copyright © 2019 Bloor. All Rights Reserved.
Also posted on: Bloor blogs

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?

This Post Has 3 Comments
  1. The picture you paint is appealing but I think it is appealing in the same way that socialism (in the true sense of the word) is appealing but has never been shown to be practical at scale.

    I have multiple points. To begin with, why is there an “application backlog”? Is it because IT is incompetent, is it because it has failed to adopt and properly implement Agile methodologies, is it because it lacks the appropriate tools, and/or is because IT is underfunded? Possibly all of these but certainly the last.

    Secondly, bear in mind that just as you are calling for citizen developers, the analytics space is calling for citizen data scientists, while associated areas are all advocating business-oriented self-service. In effect, between you, you are calling for the demise of the IT department as we have known it for 50 years, relegating it to the position of plumber. That may be no bad thing but it has implications of its own. In particular, if IT is just about hardware and plumbing it loses kudos and ceases to be an interesting place to work with a resultant lowering of skills and capabilities, much of which will be automated through the use of AI.

    This has further implications. For example, the “light touch governance” you call for will need to be overseen by the business (it should be anyway but most businesses don’t want to do it and it is mainly only happening – if it is happening [usually not] – because of pressure from IT). It will be the business that needs to ensure that GDPR, for example, is complied with, rather than IT (because IT will no longer have the relevant skills). Ditto both training and “crafting” (potential mentors will go the way of COBOL programmers).

    In other words, business departments will need a much broader skill set: development, analytics, “business” architecture, governance, security (if applications are developed by citizen developers they will have to do security testing on their applications, not to mention integration testing, performance/load testing and functional testing) and compliance. Because different departments will have different priorities this will lead to divergence in capability between departments and they will all end up using different tools, because there is no central control of buying decisions (because the plumbers have lost any power over such decisions), which will lead to even more diversified silos than we have today. I’m not sure that this is a good thing. In fact, I am sure it is not.

    This raises an interesting question: is it better to have an IT silo which, if it is doing its job, is at least trying to eliminate or at least align/integrate business silos; or is it preferable to allow business departments to proliferate and extend their individual silos? Rhetorical question, of course.

    And finally, has anyone asked business users if they want to be developers? Or data scientists? Or business architects? I don’t think so. My guess is that most people (there will be exceptions) have got enough on their plates already without heaping more requirements on them.

    I don’t disagree about the cultural change needed but I think it might be more like China’s “cultural revolution” than a mere change.

    1. Philip, I don’t disagree with much of what you say, but I do somewhat disagree with your conclusions. Not everyone will want to be a citizen developer but some will. If you expect someone in Sales to spend half their time being a developer, you will have to hire more sales people until the productivity benefits from citizen developer innovation come on line.

      I also believe in socialism and that it can be made practical at scale 🙂

      Your last comment “I don’t disagree about the cultural change needed but I think it might be more like China’s “cultural revolution” than a mere change” rather encapsulates what I was trying to get across. Betty Blocks will be a useful alternative to, say, Mendix and OutSystems. If there is a proper selection process. it will win some use cases, lose others, but this won’t deliver disruptive change.

      Disruptive change is more like the “cultural revolution”. If an organisation goes down that path it needs to think very hard about why it is going there, what it expects to achieve, how it measures its achievement and how it stays in business during the change. Disruptive change is not for everyone.

      However, organisations that do embrace disruptive change may well end up ruling their business area for decades.

      That cultural revolution in China (the PRC), did it “work”? Morally, no, it killed millions. Economically, in the short term, no. Would I like to live in the PRC today? Well, I’m going there and I’ll let you know when I get back, but I doubt it, I don’t want to live in a country that “rules the world” (the UK in the EU would do me) but it isn’t the PRC of the 1960s. Did the Cultural Revolution contribute to what the PRC is today? Presumably, yes, whether for good or bad is moot, as is whether it was worth the collateral damage (I’d say no, but I’m a wishy-washy liberal).

      The PRC today is looking like the next world power and its 5G technology is sufficiently better than its competition for the Americans to have to tilt the playing field in their favour with Trump’s tariffs rather than compete on a level playing field. Disruptive change was effective, but it had consequences. I see too much glib talk of disruptive change that takes no account of the consequences.

      I support properly thought out, properly resourced, disruptive change. If the people managing the disruptive change care about people then it won’t wreck lives, if they don’t it will (I’ve lived through disruptive change in the City of London). It is not something that can be mandated by the CEO and just left to run itself. It also doesn’t justify callous bad behaviour – ethics have to be built into the disruptive change process. More parallels with the Cultural Revolution in the PRC?

  2. Colleagues have pointed out that I may have been a little extreme in this blog. Myself, I don’t think so – I was talking about disruption and I think that NO CODE is the disruptive approach, for organisations that need a disruptive approach. I’ll comment on any specific points that get made; but remember three things:

    1/ There is a huge technology adoption tail in IT. Even when/if No CODE is accepted as the norm, there will be people happily using LOW CODE solutions, frameworks and even 3GL coding well after when I have gone. No-one should adopt NO CODE solutions unless there is a business benefit from doing so.

    2/ A new technology, especially a disruptive one, must be adopted only after proper analysis of an organisation’s needs; and after a proper selection process, including “proofs of concept” designed and run by the customer, not the vendor. And the associated cultural changes must be managed and properly resourced. Successful disruption usually takes time to implement and has an initial cost. You’d do it for a compelling reason.

    3/ From personal experience in radical process redesign, beware “malicious compliance” – from people with an investment in the status quo who adopt new disruptive technologies in such a way that they must fail, and then say “told you so, we’ll have to go back to the status quo”. A superficially attractive approach to adopting NO CODE might be to sack the IT group (thus saving lots of money), in the expectation of NO CODE productivity; buy a NO CODE product, train the business end-users in it, keep the business users’ workloads, headcounts and targets the same and expect them to act as unpaid developers in their spare time, thus increasing productivity by an order of magnitude. This, fairly obviously, isn’t going to work, so this is NOT what you’d ever do. I hope.

    Oh, and we need use cases from early adopters to give confidence in any disruptive approach to anything.

Comments are closed.