Agile working is just the beginning

In recent years, more and more companies began to work agile, with small development teams producing software in short sprints. This is a great improvement over the earlier waterfall methodology. However, the implementation of agile development is only half the battle. There is still a world to win with the introduction of better tooling.

I am always very surprised about the amount of errors in software. Developers have taken the time to develop an application, it underwent testing, and ultimately it was decided to go live with the application. You might think that, apart from some minor issues, it will work. However, the reality differs. Software often contains many errors, is written in a needlessly complicated way, and could be better described as spaghetti code. And I see that happening everywhere. Not only with SMEs, but also at institutions where you'd least expect it such as banks, telecom operators and cable companies, or defence (where I have worked for years). Software is riddled with errors, with devastating consequences. Developers are only solving old problems and fixing bugs. 'Keeping the lights on' is a goal in itself and there is no innovation. It would scare us if we wouldn't find it so normal because it happens so often.

Better code and less risk


However, in the last few years, thanks to the introduction of agile development methods, things have started to improve. After all, agile tackled an important issue: it enables you to detect errors earlier. While errors only emerged after months of development with classical software development, it now happens after one development sprint. For an organization, this decreases the risk: if you're not on the right track, you'll lose just a few weeks. A proper containment of waste. Agile development makes projects flexible, which is desperately needed in software development.

Yet, the agile methodology is, in my view, taking development only half a step forward. Although it constrains the consequences of bad software, it does not tackle the causes. The point is that it is often very difficult to assess where problems are ultimately going to manifest themselves (let alone do root cause analysis when things go wrong..). An application has such an awful lot of execution paths... You can't possibly predict all outcomes as a human being. Especially when that application is linked to other systems. Many IT specialists therefore simply choose to put an application live, automatically demonstrating its errors.

Spectacular results


Agile won't change those programmers' errors. Nowadays, however, there is tooling that enables you to make less mistakes as a developer. This is especially applicable for low-code development platforms that enable programmers to visually model applications. The developer will then draw a corresponding data model, based on standardized building blocks of code. The primary advantage of this is that it enables you to ‘program’ much faster. But perhaps more important, it ensures the organization of having good, and easily maintainable application. In addition, OutSystems platform also has a built-in dependency check. During development, it automatically checks whether the applications that are made within the OutSystems platform, as well as the links to other systems, can also be linked to the software of the existing application landscape, without 'something else collapsing' down the line.

The success of the OutSystems development platform is spectacular, as was recently, for example, determined by KPMG. It can be used to reduce the 'keeping the lights on' effect by 50 to 75%(!). If you compare that with the cost of software across the entire lifecycle (often 3 to 5 times the purchasing cost; according to Gartner this can be up to 7 times), this is huge. It has enormous consequences for the app life cycle and it also confirms my conviction: an ideal IT environment is a combination of good processes, good people and good tooling. Agile working has addressed the processes. Now it's time for the tooling!