No-code/Low-code is software DIY - how do you avoid DIY disaster?
TLDR; Much like how DIY tools empower individuals to undertake home improvements without professional intervention, No-code/Low-code platforms aim to democratise the process of building software, empowering users without the need for extensive coding expertise. They can be incredibly powerful and may be a perfect fit for your needs, but before you dive in to embrace these platforms fully it's important to understand the broader context of software engineering. For example, critical factors such as testing, security and regulations can often be an afterthought in this type of tooling, so it's important to properly evaluate No-Code/low-code in the context of your requirements and capabilities so you can make an informed decision.
Software engineering and construction
There's a long established, and often referenced analogy between the software industry and the construction industry - the notion of building/construction is baked into the language and artefacts of technical teams and projects (architects/architecture/blueprints etc.), and a lot of traditional IT project processes are modelled around established planning and estimation tools in the construction trade.
Of course, the analogy is totally flawed and there are a million valid and justified opinions out there as to why it's wrong. This post is definitely not an attempt to reignite that debate but, given its widespread familiarity, it's a useful analogy to explore when considering how trends in software development have evolved over time - specifically the continued rise in and adoption of No-code/Low-code platforms, and what that means for your organisation.
So here we go - No-code/Low-code is to software development, as DIY is to the construction industry.
Explaining that a bit further, just as the DIY industry is geared around helping the general population do home improvements without the need for "a professional", No-code/Low-code is about empowering anyone to develop a software solution without the need for a trained expert i.e. a software engineer.
Exploring the analogy
No-code/Low-code software development isn't a new concept. Drag and drop user interfaces, wizard-based code generation, WYSIWYG content editors, even Excel - they've all been around for a long time. And the DIY industry isn't new either - it started to grow in the 1950s/60s and is now worth billions of dollars globally. Whether that's tools, hardware stores, books or YouTube tutorials, there's a huge appetite for DIY.
But despite our appetite for doing it ourselves, this hasn't destroyed the construction industry. Both exist side by side, and for the most part, people seem to understand where the line is between what you might want to tackle yourself and when you might want to pay for a professional. That line is going to be different for different people - of course, factors such as time and money are always going to have an impact, but the interesting bit is around capability. Most people would understand the difference between re-painting a bedroom and knocking down walls, and be able to make a judgement call based on where their comfort level was.
I'd argue that this judgement call is harder to make when it comes to software. And I think the reason for that is because building software isn't like building buildings at all. You can't "see" a lot of what's being built, which means it's much harder to gauge what's going on, how big or risky the job is, and how long it might take to complete. This isn't a statement around intelligence - simply put, it's harder to understand or comprehend the work or processes involved when they're not in plain sight.
The truth is that the bit you can see - the code, or the user interface - is really just a small portion of the overall process of developing software That's a significant point, as in that context, No-code/Low-code only deals with that small portion too. When you think of it like that, it's easy to see how things can go awry. So what about the rest? What engineering practices are missing that add rigour and confidence? How does the "power user" make an informed judgement as to whether their problem could be solved by a No-code/Low-code solution, and when they should consider professional software engineering?
Well, at risk of pushing a bad analogy too far, let's look at this through the lens of some classic #diyfails:
1. Using the wrong tools for the job
Ever tried to use the wrong nails, wrong screws, wrong drill bit, wrong glue, wrong paint... and then regretted it? Yes, me too. And more fundamentally, have you ever tried to use nails when, in fact, you should actually have used screws or glue all along?
What we're talking about here is understanding the requirements - both functional and non-functional.
The classic saying "When all you have is a hammer, everything looks like a nail" is very applicable here! Just because you have a No-code/Low-code option readily available, it doesn't necessarily mean it's the right choice. The challenge with No-code/Low-code is often that the "easy" stuff is very easy to do. You can be easily swayed by rapid progress early on, but get caught out in the long tail of features/requirements that become a lot more difficult to implement without all the flexibility of bespoke software engineering. So, do you fully understand the requirements around the solution/system/application you want to develop, and do you know that your No-code/Low-code platform can deliver them?
Non-functional requirements capture not what the thing does, but how it does it (is the glue strong enough, are the nails long enough etc.). No-code/Low-code focusses a lot on "doing the thing" which makes it an attractive choice. But is it still the right choice when you factor in your non-functional constraints? This might include performance (is it fast enough), scale (will it go large enough), accessibility (is it usable enough) or security (is it safe enough - more on this below)? Have you thought about these non-functional requirements in the context of your No-code/Low-code solution?
2. Ignoring health and safety
Do you always switch off your electricity before you drill into a wall? Do you always wear safety goggles? Possibly not, but you probably know that you should, right? I'm guessing most people have experienced some form of minor DIY injury (hopefully nothing serious!). If you've ever hit your thumb with a hammer you know the feeling - and probably followed it up with some not-safe-for-work language!
So what could cause you pain when building software? Security breaches are an obvious one - how painful/damaging would it be if someone gained unauthorised access, or your data ended up in the wrong hands? How does your solution control, manage and audit access? A word that's often mentioned alongside No-code/Low-code is "democratisation" - i.e. more power to more people. But depending on what your solution does, tighter controls might be necessary - or do you understand and accept the risks?
And what about financial pain? You might get going very quickly and cheaply with a simple example - especially with simple credit card sign ups. But what happens when you unleash things across an entire document library/database/organisation directory? Have you done any cost modelling, and does your No-code/Low-code solution allow you to set policies or budget restrictions to stop you feeling the sting in your wallet?
3. Ignoring codes or regulations
You're probably aware, at least to some degree, of your local building laws and planning regulations. Here in the UK we have Building Regulations, as well as something called Permitted Development which lays out what you can and can't do before you need to seek proper Planning Permission. Utilities have their own regulations - gas installation needs to be Gas Safe and electrical work should be carried out by a registered electrician to ensure that it's compliant with the associated wiring regulations. You probably wouldn't embark on doing anything in these areas if you weren't a trained and certified professional as it's easy to understand the legal ramifications.
But are you aware of how regulations might affect your software solution? The most obvious way that it will is in the processing and storage of data. It would be hard to avoid being impacted by the EU General Data Protection Regulation (GDPR), or it's post-Brexit UK equivalent, if you're doing anything with any form of personal information (data that relates to an identified or identifiable individual). This has serious ramifications and even organisations that really should know better are being hit with enormous fines for GDPR breaches.
As well as general regulations, many organisations have industry specific regulations. Financial Services, Healthcare and Education immediately spring to mind, but there are many others. This might impact everything from data retention policies (how long you can hold on to data for), to sovereignty (in which geographical regions can the data live?). Not understanding the regulatory concerns that apply to your system could get your organisation (or in some cases, you personally) in serious legal trouble.
So, do you understand where your data is going to live in your No-code/Low-code solution, how it's going to being processed and managed, and what would happen if you needed to respond to a GDPR request?
4. Not measuring properly
The old adage "measure twice, cut once" is often recited, but do you always follow the advice? And if you don't, how many times has it caught you out! The point here is about checking or validating what you're doing - ensuring accuracy from the offset so that you get things right first time and don't end up with costly re-work. To avoid having to buy more materials, fill holes, or completely start a project again, the more confidence you have in the work you're doing, the better.
The notion of measurement, accuracy and validation translates nicely into testing software. And just as the "measure twice, cut once" wisdom is designed to prevent issues occurring before they happen, the same is true in software that the earlier you understand that something is, or could be wrong, the quicker and cheaper it is to remedy. Testing code and fixing bugs whilst still in development is very different from dealing with defects that have made it into production systems.
The problem with No-code/Low-code solutions is that testing isn't generally factored into the process. The focus is on productivity - getting something built or working quickly to add value - rather than starting with a comprehensive set of test cases to work with. When you add in the satisfaction that a lot of people get with seeing something come to life, whether that's numbers light up in a report, a web page loading, or a notification magically popping up, you can see why it's easy to forget about the quality assurance process.
Quality Assurance and Quantity Surveying are key aspects of a construction project. Similarly, in the world of professional software engineering, we have a myriad of tools, frameworks, approaches and opinions on testing. Some people make this their entire career. How or who is going to test your No-code/Low-code solution?
5. Being overly confident
We've all started jobs that end up half-finished because they ended up being a lot bigger than we expected! Sometimes its easy to estimate how long something might take - say painting a bedroom - especially if you've done it before. A bigger room would take longer, and a smaller room would be quicker. But what about the jobs that you haven't done before, or fully grasped what's involved? Would you jump straight in, or would you stand back and try and understand the full scope of the job first? And at what point would you suck your teeth and decide maybe this wasn't something you wanted to do yourself after all?
No-code/Low-code solutions focus on rapid delivery, and in some cases this can lead to a false confidence regarding the scale of the task, or the progress being made. Sure, you might be able to put some initial screens or processes together really quickly, but once you start factoring in a lot of the things discussed in the points above, does it still result in a quicker/cheaper/better outcome?
That's a really hard one to evaluate - even a lot of seasoned software professionals struggle with the non-technical aspects of the job - estimation, planning, requirements definition, stakeholder management and communication etc. But that doesn't mean that it's not important - creating a bill of materials, understanding the cost of development, and the impact of stakeholder changes on budget and schedules, are all part and parcel of any sizeable construction project, and should absolutely be part of a software project too.
Summary
The point of this post is that it's really only possible to start evaluating whether No-code/Low-code is the right choice if you understand the wider context around what it takes to build software.
There are many examples of organisations starting out with No-code/Low-code solutions that have rapidly become more and more complex, to the point where it's clear that, with hindsight, that was the wrong choice. The issues encountered with the Test and Trace reporting by Public Health England during the Covid pandemic is one such example. I've described in detail previously why I think things went wrong here, but the first step in that was that the choice of technology (Excel) was based on ease and speed of use, rather than ensuring the quality of output.
As the availability and capability of No-code/Low-code continues to increase, businesses are making increasing demands on this type of workflow, which means that business critical systems and processes are running on top of DIY built solutions.
So the advice here is, before jumping straight in, try to understand the bigger picture. No-code/Low-code may absolutely be a perfect fit, but equally it may not.
Do you understand the size, scale, risk, complexity of the job in hand? Do the people in the team have the capability (and confidence) to take it on? And do you understand where the gaps in that knowledge are - what it is that you don't know?
If the answer to those questions is yes, then No-code/Low-code may indeed be the perfect fit. But if the answer is no, then maybe it's still time to get the professionals in.
