What is Low Code? What is No Code? How can they help us? I touched on this subject during the Tech Pro Unicorn episode (#114), but had a lot more notes than could be covered - thus in this episode, I take a deeper dive.
Or listen at:
Published: Thu, 13 Jan 2022 08:34:11 GMT
Links
Transcript
Hello, and welcome back to the Better ROI from Software Development podcast.
In this episode, I'm going to talk about Low-Code/ No-Code.
I touched on this subject in the Tech Pro Unicorn podcast that I was able to kindly re-post under episode 114. I'd made more notes than I could cover in the Tech Pro Unicorn podcast, so I wanted to use this episode as an opportunity to take a deeper dive.
So let's start with what Low-Code/ No-Code is.
I'm going to quote from Harvard Business Review article - I'll actually include the article in the show notes. The article describes Low-Code/ No-Code as:
"they turn over development to users instead of professional system developers. With point-and-click or pull-down menu interfaces, users can usually design and implement their individual or departmental systems in a few hours. The software may also have a conversational or search interface. Few, if any, programming skills are required."
The article also goes on to say:.
"This greatly expands the population of people who can build software applications within a business. Low-code software - which, as its name suggests, may still require some level of programming skills - is typically used by professional software developers or hybrid business/IT employees to improve their productivity. No-code software is suitable for use by nontechnical businesspeople, sometimes known as "citizen developers."
For many companies, this helps them digitize and automate tasks and processes faster than trying to hire and onboard hard-to-source development talent. However, there's an important caveat: LC/NC software does require some level of IT involvement when they touch mission-critical or enterprise-wide systems. As companies look to LC/NC solutions, they need to be aware that these platforms - while offering cost saving, time and error reduction, and other improvement opportunities - still require some level of technical expertise to scale, maintain, integrate, and govern."
The article summarises with:.
"Almost every organization today needs more system development talent. LC/NC development isn't a panacea, but it can address some of these resource shortages. Over time, it's likely that systems will become even easier to build for common processes and use cases."
So let's focus on the benefits.
It expands the people that can increase productivity through our computer systems, and so much of our modern world relies on technology. And this is only going to get greater and greater as time moves on. Thus, democratising some of that power locked away traditionally in IT departments, makes sense. And I will always be in favour of shortening the gap between the business experts and the technical coalface.
We also need to be aware that sometimes there's dangers in this, and this can lead to what is known as "Shadow-IT".
Wikipedia describes Shadow-IT as:
"In big organizations, shadow IT refers to information technology (IT) systems deployed by departments other than the central IT department, to work around the shortcomings of the central information systems."
Wikipedia also goes on to describe some of it as positive:.
"Shadow IT systems are an important source of innovation, and shadow systems may become prototypes for future central IT solutions."
These Shadow-IT projects are often seen as negative by the IT teams.
Rarely is there a handover of that prototype into IT government. It generally comes back over the wall to IT when there's a problem.
In the Tech Pro Unicorn podcast, I talked about it having to solve problems with a critical Excel spreadsheet - an Excel spreadsheet built by somebody in finance with very custom macros. The Excel spreadsheet was exceptionally complicated. It worked for what the business did and the business relied on it. But nobody in IT could understand it. It was written very specifically by one person for one person. Nobody had an idea of how to support it or look after it.
We also talked about the idea that potentially a CIO may suddenly find that there's a problem with a Salesforce implementation, which they didn't even know existed in the organisation because a department had signed up for it themselves with a credit card.
The dangers of the Shadow-IT, of departments going and doing their own thing, falling down when suddenly there was a need for governance or support from the wide right IT community.
And Michael even said in the podcast, he'd worked with a company that audited these things. And he talked about how in one instance, they demonstrated a considerable amount of systems the IT were not aware of that the rest of the organisation was using and relying on without their knowledge.
So for me "here be dragons"; as the Harvard Business Review says, this is not a panacea.
And as I warned in the Tech Pro Unicorn podcast, software development is a very young industry. It's still learning how to do things professionally. As such, we need to make sure that any efforts of Low-Code/ No-Code learn from those mistakes that we've made over the last 10, 20, 30, 40 years of software development.
We need to take advantage of things like version control so that we know who change what and when. We need to make sure that we can safely roll out changes and roll them back if something goes wrong. We need to make sure that we've got testing and validation. We need to make sure that we've got appropriate security and governance controls - think about all that personal identifiable information - think about PCI. We need to make sure more than one person knows how to use it. We need to look at peer review so that multiple sets of eyes have looked at it, making sure again going back to the security governance, making sure the quality is there and of course, knowledge sharing so that if that individual that wrote it goes on holiday, it still works and people can change it and maintain it.
In short, we really need IT guardrails. We need to help the citizen developer "fall into the pit of success".
In the Tech Pro Unicorn podcast, Michael also raised the dangers of Low-Code/ No-Code capabilities being oversold, either as part of another system that you're buying or as an entirely new product. Being oversold the dream of not needing IT where the business could do it themselves.
Now this worries me because this is effectively pushing departments and teams into that Shadow-IT realm. It should never be without IT. If there's a problem with the relationship with IT, fix that problem. Circumnavigating IT - which may seem expedient and I can understand why people would want to do it if they're struggling to get stuff done and they need to move forward - but circumventing it will result in massive problems down the line.
I'd also suggest if it's being sold as a feature of a product, you may find that it's simply bloating the product that you're paying for.
You could be paying for functionality that you simply do not want or need. You could be overpaying, something I talked about in Build versus Buy in the last episode.
If you are looking into Low-Code/ No-Code, then you need to apply those same professional software development principles to that exercise. You probably need to have some sort of shadowing by the software developers to that citizen developer as they work.
Michael actually had talked about where he'd done a direct comparison between using business users and professional software developers using the same tools. He found that the professional software developers produced a much better job, not only accomplishing the task quicker than the citizen developer, but also making sure there were tests, making sure it had better quality, making sure that it was documented.
Whereas out of the business users, only one out of the two managed to complete the task and nowhere to the same level as a software developer - which, to be honest, isn't a surprise.
The software developers have gained skill over time, whether it's been taught at university or learnt on the job, they've learnt how to make things secure, they've learnt how to make things testable, they've learnt how to document these things.
Whereas the citizen developer, they haven't been through that training.
They haven't been through the growing pains of the software development industry.
By software developers shadowing and providing a consultancy, we can build and grow a learning culture by sharing those experiences and why software developers do the things they do.
And while Low-Code/ No-Code may help with technical shortfall, it should never be considered for cost savings alone, as it will never do that. It is not a direct replacement for what may be seen as expensive software developers.
In this episode, I revisited Low-Code/ No-Code.
I've gone into a bit more detail than I managed to do in the interview. And for me, I believe there is a place for Low-Code/ No-Code, a valuable one, and I think that's going to only grow over time.
But with great power comes great responsibility. And as a business, as an organisation that needs to be fought through as to how we will use it with that great responsibility.
It is not a fix for a broken relationship with IT.
It is not a cheaper way of avoiding software developers.
It is not a silver bullet.
It is another tool for the tool belt and needs to be used for the correct tasks in a safe and responsible manner.
Thank you for taking the time to listen to this podcast episode. I look forward to speaking to you again next week.