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

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.