I’ve been writing custom software for a long time and one of the things that annoys me most is when a client adopts the position that there is a silver bullet which will reduce or remove the inherent complexity of this task. This happens more often than you’d think and guess what? They are almost always wrong.
Perhaps I’m getting a bit too old and loose lipped for my own good, but the truth is that creating software for other people is exceedingly difficult. Contrary to the opinions of non-practitioners (aka non-coders), this difficulty is not the fault of coding languages, tools and paradigms. It is actually the result of clients and developers not taking the time to understand the root causes of the problems they want to solve and not designing a solution around the conclusions you’d draw from that process.
It isn’t enough to code the tool as specified by the client. The first step before you start coding is to validate the existence and the details of the problem itself. Most coding projects are initiated after the client realizes that they have a problem and decide to ask for code which they think will resolve it. The reality is that most clients are not professional problem solvers, whereas that is precisely what Software Developers do. It therefore falls upon our shoulders to validate the approach suggested by the client before we possibly waste both their time and money developing it.
So let’s be clear: I’m not disparaging clients. They know they have a problem, they just might not fully understand how to design and implement the most sensible and appropriate solution to that problem. Sometimes, it doesn’t even make sense to write any code to solve some of the problems I have been presented with over the years. That’s because in a lot of cases, the problem at hand is actually a process problem. But from the client’s perspective, it’s easier to pay somebody to code a tool to solve a problem than to attempt to change an entrenched process.
I previously touched on this idea back in 2019 in my post “Why I Can’t STFU And Just Code A Solution To Your Problems”:
The easiest way to explain my mindset is as follows. I’m a professional problem solver whose primary tool is code. People don’t come to me and ask me to write code because everything is hunky dory. On the contrary they come to me and ask me to code a solution for whatever problem they are currently experiencing.
In any event, if you get past all this, its time to write some code, right? Well usually. That’s where this blog post comes in. Sometimes a client falls into the trap of believing that there is some kind of silver bullet they can employ which will negate the inherent complexity around coding custom solutions. Nowadays the most cliche form of this is to say, “Well I’ll just ask ChatGPT to code that for me”. I declare shenanigans. While ChatGPT can handle some simple coding tasks, anything beyond that causes it to rapidly devolve into an unmanageable mess.
Beyond the in vogue AI Chatbot example, there are a wide variety of other snake oil tools lingering about. All of them sell prospective buyers on the premise of allowing them to cut through the cruft and quickly pump out custom software without going through the years of training that professional Software Developers tend to go through. The most relevant example of this syndrome are so-called low code tools. As it so happens, I work with one of these at my current job.
This low-code tool is called OutSystems and my review of it is that its a steaming pile of shit. I won’t go into the technical specifics of why as that probably deserves it’s own post. While it has enabled some non-developers to produce custom logic and screens, it hasn’t actually removed the inherent complexity around designing proper data structures, writing fault tolerant software and validating the quality of the resulting software. Because a lot of the coders in question don’t have this expertise, the end result is a custom software system that is poorly thought through, is brittle and as a result will require constant fire fighting on the part of the future members of the team in an effort to keep it functional.
I haven’t even mentioned the best part: Tools like this aren’t cheap and they tend to structure their licenses / billing so that you end up paying for as long as you use the software you produce with the tool. On top of which, all of these tools seem to involve accepting some level of vendor lock-in. So the more time you put into tools like these, the tighter their grip on your proverbial balls becomes.
In both the AI Chatbot and the Low Code tool scenarios, the solutions each promise a shortcut around the complexity as perceived by a non-practitioner. That’s the essence of the trap. Practitioners know that the writing of the code is merely the last step in a long process that involves a lot of thinking, discussion and planning. The code is generally the end result and producing it is relatively easy once you truly understand the problem at hand.
TLDR: Designing a pragmatic and efficient solution is actually the most difficult part of the software development process. Low Code tools lie to customers by implying that the writing of code is the hardest part. The reality is that No Low Code tool can spare you from having to take the time to properly design your custom software or the consequences you will experience when you build solutions around an ill-considered design.