Continuous Thinking: Why a 4GL Should Be Avoided to Start a New App

Introduction

As an avid member of the DDD/CQRS discussion group, somebody asked me what I meant by the following sentence:

it looks a lot like a 4GL, and I assume we all know what that means...

Since I tend to think my answer formulated my ideas pretty well, I decided to post it on my blog too; I hope this might help some of you to avoid the 4GL pitfall...

Why Should a Business Avoid Writing Apps in a 4GL ?

This was my answer:

WARNING: This might be a bit off-topic here, but I do want to clarify my **PERSONAL** opinion on 4GLs.

[AD MODE]As an independent consultant, one of my key specializations is brownfield migrations (together with non-communicating teams).[/AD MODE]

Having seen numerous examples, I think most of these homegrown x-year old+ MSAccess or similar applications are usually the perfect example of why one should respect the SOLID principles.

Here a typical evolution of a 4GL app:
There is a business need for a small piece of software (think CRUD client list), which does not need to do a lot. So someone drags and drops a CRUD app together in a few hours/days/weeks depending on the scope... Everybody is thrilled and excited about the custom piece of software, which was developed in a fraction of the time, it is custom built, cheaper, [Add the obvious here],....

Unfortunately, an app is bound to grow more complicated as the business is evolving, f.e. "Could you add products/quotes/","except for this and that this should do that", ...

After some time, such an app is also bound to have "user hacks" (i.e. changing a field's meaning to work around a limitation for example, because it would cost too much to implement the change), so when this specific coworker is on holiday, nobody knows how to work with the app...
Educating new users/software devs might also become quite a steep hill to climb.

I usually get consulted by the time the app has been growing for about 3 to 10 years into an unmaintainable behemoth with a massive amount of implicit business knowledge in it, where a single change might break everything or take numerous days to implement,

Unfortunately, there is no nearby river available to clean this kind of Augeas stable. I do not intend to describe the whole process we need to go through, but I can assure you it takes a lot of time/effort/resources, and requires quite a lot of engagement from both the management and the software team.

A business in this kind of situation needs to handle this problem, better sooner then later, because it is bound to constrain the business growth/evolution sooner or later.

[sarcastic mode] If you do decide to implement an app in a 4GL, please send me your coordinates, and I will give you a call in about a year or 3 [/sarcastic mode]

Conclusion

In my honest opinion, a 4GL should never be used to implement business logic; if you do break this rule, you are bound to get into problematic situations sooner or later; in case you do decide on using a 4GL, I would strongly advise to use it only for the front-end, and respect the SOLID principles.