Why is software so hard?

In other words: “why is software so difficult”, but in English it has a nice double meaning. Because sometimes it seems as if software has become the ‘hardest’ part. I regularly come across situations in companies that use software from 30 years ago or more, with fairly minimal adjustments. The rest of the company has already changed completely at that time: it makes different products, different people work there, people have already switched offices twice. The hardware that the software runs on has also been replaced at least once. So what’s actually ‘soft’ about that software?

If you check the literature, supplemented with some personal experience, one problem emerges as a constant: it is difficult to fully understand what a piece of software of any complexity does. With a good development team, this should still be possible during the construction phase, but software that lasts longer requires more. Even if it has lingered for years, it must be possible to understand the specifications and then make adjustments. Alan has certain features that make this possible, even in the long run, but more on that later in this article. First I will discuss why this is so difficult with current software technology.

How do you actually do that, understand how software works at a later point in time? Well, that will come down to understanding the source code of that software, understanding its ‘operation’ and being able to predict and understand how it connects to the desired functionality of the software. Not everything in the source code is equally important to understand the intended function of software. For the specific function of the software, you need to understand the essential elements, which I referred to as a domain model in a previous article .

However, in our current software technology there is no clear separation between the functional elements of software and the rest. Everything can be equally important. And to add to the problem: functional elements can appear anywhere! The user interface contains part of the puzzle, in the data model, in the logic / processes and, of course, in the various system interfaces. This is the case in all current software platforms, also in the current low and no code solutions, I have also written about this before .

I therefore reveal an public secret when I say: many organizations with legacy software do not know exactly how their software works. This is to be expected, because as if the task I just described is not difficult enough yet, it is often made more difficult. Because there is a quick way to get around the understanding the current software: just build an extra layer of software around it.

To make that concrete: if the sales department has a problem with the current software, because it cannot adjust the delivery dates of the current orders, they might prefer to adjust the software, but who will do that? It is often too expensive to get a development team to act on it and I am not even talking about the risks of such an approach. No, what happens at first is that an Excel is kept with the actual delivery dates and after some problems, because other departments do not know about it, a new piece of software is created that passes these dates in parallel with the existing software. It works, but in this way an extra layer of complexity has been added to the whole.

In this way, it is common for organizations to have collected hundreds or even thousands of applications and they need to keep them under management. All without strict interfaces and with different parts per application where you should get the essentials. It is difficult enough to keep something like this running, but making adjustments to this is an almost impossible task. That is why companies regularly end up with a ‘software bankruptcy’, in which the legacy software will have to be abandoned in one big bang — if at all possible.

There are of course enormous risks associated with a complete replacement of legacy software. The legacy software works in a context of users and systems that are adapted to it. Subtle, useful variations in functionality, problems that have been worked around and conventions that are not recorded anywhere (yes, in that field ‘freefield1’ we always fill in the height) all come up mercilessly when any new software is put into operation.

But the biggest problem of a legacy replacement is actually the following: is the replacement really better and can thus prevent the same situation from occurring? If the replacement does not have strict interfaces and a complete, consistent and concrete domain model where all important functional elements of the application have been laid down, I dare predict that the same problems will arise in the new situation, so that after a few years the same legacy situation will arise again: too much complexity to be able to understand and adjust it properly.

Alan

Alan does have those features and is therefore an ideal platform to replace legacy. Without the previous problems reappearing. All software built on Alan remains easily customizable, extendable and easy to change. Some of the applications built on Alan have been in use for 8 years, in a demanding 24/7 production environment, and are still being expanded and modified regularly.

The speed with which we are able to make and roll out changes has only increased over time, due to the improvements we have made to Alan over time. Think of hours or days to be able to have changes in production, where people were used to weeks or months to be able to do the same in a previous solution.

If you would like to upgrade your legacy software, you should consider using Alan. It can provide you a solution for the increasing costs of adjustments and adverse effects on stability of changes to your current systems. Feel free to contact us and do a pilot project with us to see what benefits we could offer you.

Report this

Originally published at https://www.linkedin.com.