About 3 decades ago, there was a time when the business world pursued the automation of software engineering work. It was believed that computers could be used to automate the development of very software that would run computers. CASE – computer aided software engineering – was invested into, attempted in multiple ways. Millions of hours were invested into making it a reality. Those in the industry know where that went

We are back to it again… we just call it fancier name now – ‘No Code’ software. I firmly believe that software engineering must be simplified. Software is pervasive today. There is hardly an area of human life that software does not touch. It’s absolutely imperative that it become a whole lot easier to manage the engineering and subsequent maintenance of software.

Software is basically code. Code that tells computing resources what to do. So there is no such thing as ‘no-code’. Yes, we may aspire for the day that humans wont write the code or wont be writing as much code as in the past. However the more pervasive and extensively software is used, the lesser the chance that no-code will be a reality. Less code on the other hand is a better aspiration.

The software industry has struggled to even realize the benefits of software re-use yet. A simple assessment of a small sample of firms using software or building software will indicate that there are engineering teams still writing their own exception handlers, notification mechanisms. There is constant push needed even today to uphold the principles of object orientation and procedural programming. A significant majority of the software engineering still occurs by accident. The situations where engineering tools, stack components, patterns are chosen through thinking and deliberation are far and few. There is a lack of discipline and respect for software lifecycle models and associated artifacts. When reuse at the most basic levels is missing within teams, let alone within groups or organizations seeking rationalization of the practices at an industry level is perhaps asking for too much.

It is also surprising that this perhaps is the only industry where there is a drive to commodify a specialized engineering skillset (albeit that not too many in the industry may represent an engineering approach to software creation) into ‘nothingness’, and undermine the critical value of the engineering lifecycle. In no other industry has this happened in the past. No one ever says that we allow the car buyer to manufacture her/his own car or allow a smartphone user to build their own smartphone or allow the local community to build their bridge or lay their own electrical lines or sewers. It is mind-bogging that this notion lets allow users to build their own software. It’s one thing to increase user participation in the development of systems that serve them. Thats what ‘agile’ as a process is meant to do. The reality – agile has done little or nothing to help with it. The more the industry has spoken of agile, the fewer the outcomes that have resulted. In fact, it’s found that the higher the use of an agile mindset’ the lesser the discipline in building ‘production strength’ software. Another reality – users really have not enough time to dedicate themselves into the daily stand-ups and frequent exchange of software developed. They have full-time jobs.

Users are having difficulty using software that has been developed. Some may attribute that to the fact that ‘elite professionals’ sitting in the backroom called technology dev or IT do not understand what the users are asking for or how they will use it. Indeed it may be somewhat attributable to that. But the answer to that problem is not to say that we push the entire onus of engineering systems to the users. As it is the supposed ease of acquiring so called ‘cloud based capabilities’ brought about an era where business users were buying systems, applications, components at their will because software vendors were now knocking on their door instead of approach technology departments. The sale may been easier. However what that led to was a whole bunch isolated software systems that were islands in themselves. No external software vendor understands an organization’s entire software portfolio and can find methods to seamlessly integrate their new introduction into the existing ecosystem. They have to rely on internal software teams or departments for that help. Some can call it an elite group that holds the keys to the ecosystem, but what is new about that. Doesn’t finance hold the keys to the books of the company?, Doesn’t marketing do the same for lead generation?, doesn’t operations do the same. Nowhere does anyone ever speak about pushing those responsibilities out to the hands of users.

In summarizing, this comes down the distinction between giving the users the ability to plug their appliance into a wall socket versus letting them build their generation station. Looked at another way, we aren’t even sure how many users (i am sure there are some) want to build their own systems and sustain them.

Building and managing ‘production strength’ systems or the infrastructure beneath them is no small task. It is very inspiring to speak about no-code software and I am not saying that someday this wont be reality. However, it’s important to remain realistic about whats possible today given precedence and current context.

CJ