I’ve been writing custom software for many years, and one of the situations that irritates me the most is when the client takes the position that there is some kind of lifesaver that will reduce, if not eliminate all the complexity inherent in a given task. This happens more often than you might think, and you know what? Such clients are almost always mistaken.
I may be getting more chatty with age than I should be, but the truth is that creating programs for other people is an incredibly difficult task. And the problem here is not in programming languages, tools and paradigms, as those who are far from the practical side (that is, do not write code) tend to believe. In fact, the difficulties arise because customers and developers do not take the time to get to the bottom of the problem they are trying to solve and do not design the solution based on the conclusions that they come to in the process.
It is not enough just to develop such a tool as the client describes. The very first step before writing the code is to confirm the existence of the problem in principle and clarify the details. Most development projects start with the client realizing they have a problem and ordering code that they think will solve it. But in reality, the majority of clients are not looking for solutions to problems on a professional level, while developers are doing just that. Thus, it is on our shoulders that the responsibility for validating the approach proposed by the client falls before we start wasting both his time and money, and possibly in vain.
Here it is necessary to clarify: I say this without disregard for clients. They have a problem, and they understand it – only they may lack understanding of how to design and implement the most reasonable and appropriate solution to this problem. Over the years, I have encountered such problems for the solution of which it was generally pointless to write code. The reason is that in many cases the problem is actually in the processes. But from the client’s point of view, it’s easier to pay someone to develop a tool that supposedly fixes it than it is to try to change deeply rooted practices.
I already touched on this topic in 2019 in the article titled “Why can’t I just shut up and write a solution to your problem”:
The easiest way to express my attitude to this is this: I am a professional problem solver, and my main tool for this is code. People come to me and ask for some kind of code, not because they have everything in the ointment. On the contrary, they come and ask to write a solution for the difficulties they are experiencing at the moment.
In any case, when all these initial stages are passed, it’s time to write code, right? Well, usually it is. And this is where we come to the main topic of this article. Sometimes the client falls into the trap of believing that there is a lifesaver that will negate any of the complexities inherent in developing a custom solution. Nowadays, the most hackneyed version of this approach is when they say: “Well, let ChatGPT write me what I need there.”
. Some simple coding tasks can be done by ChatGPT, but anything beyond that quickly turns into an uncontrollable mess.
In addition to the now fashionable AI chatbot example, there are many other examples of homeopathy from development scattered around us. All of them lure potential buyers with promises to shake off all the husks and quickly put together custom software without forcing a person to spend whole years on training, as professional developers usually do. The most striking example of this syndrome is the so-called low-code tools. It so happened that I have to deal with one of these for work.
This low-code tool is called OutSystems, and I can only say one thing about it: a bunch of garbage. I will not delve into the technical substantiation of my opinion – this, perhaps, will draw on a separate article. While it allows non-developers to create custom logic and screens, the complexity inherent in tasks such as designing data structures well, writing fault-tolerant software, and checking the quality of the final product does not go away. Due to the fact that many of those who work with the code using such tools do not have the appropriate knowledge, the result is ill-conceived, fragile custom software, respectively, the future team will have to constantly put out fires so that it somehow functions.
And I have not yet reached the most interesting part: the price tag of such tools is high, and their creators usually formulate a license and payment terms in such a way that you have to pay as long as the software created with their tool is used. In addition, all of these tools usually assume that you agree to some degree of vendor lock-in. Thus, the more time you spend on them, the tighter they hold you by the throat.
In both scenarios – both with AI chatbots and with low-code tools – in the opinion of a person who does not develop himself, the solutions promise results, bypassing all the difficulties associated with this process. Therein lies the trap. Those who work with code themselves know that writing it is the very last step in a long process that requires a lot of thought, discussion, and planning. Code, in general, is the end result, and it’s relatively easy to create if you’re really into the problem at hand.
In short, the hardest part of the software development process is actually designing a solution that is good for something. Low-code tools deceive their users by making it look like the hardest part is writing the code. The truth is, there is no such low-code tool in the world that would save you from the need to slowly and carefully think about how your custom software will work, or save you from the consequences of creating a solution designed as it should be.