Dear community, I think saving money by reducing quality is a bad idea. In the food sector, this has already taken on very bad forms. Unfortunately, it has also happened in other areas.
In connection with ABAP developments, I often hear the question of whether it is possible to decide in advance when a development must be of high or low quality.
In the first case, you have to invest time and know-how; in the latter case, you can save time and know-how. Of course, time and know-how ultimately equal money, because someone has to be paid for it. It makes a difference whether it is a junior or senior developer.
What could be saved in terms of quality
The term “quality” also needs to be explained in this context. Here are some examples of what you can do to save costs:
- Don’t worry too much beforehand and start development more quickly.
- Program procedurally rather than object-oriented.
- If you’re going to use object-oriented, then do without some classes.
- Write longer methods.
- Make data as global as possible so that every part of the program can manipulate it without hindrance.
- Generalize error handling as much as possible.
- Write few or no unit tests.
- Save yourself developer tests and hand the application over to the specialist department for testing as quickly as possible.
- Recycle, copy and let artificial intelligence generate program parts without adapting them to your context.
- Do without any form of documentation or knowledge transfer related to the respective development.
If all of this sounds familiar: This is largely the opposite of CleanABAP and describes the working mode that unfortunately many developers and entire teams are in. Some are self-inflicted, others are forced into it by external circumstances.
Why I am against a reduction in quality
Because of the idea of making a decision in advance and saving money: I can “almost” not recommend that. I’ll come to the exceptions at the end of the blog.
First of all, here are my reasons why you shouldn’t make a distinction:
- You usually don’t know in advance how long a development will be in use. The best example is SAP’s developments. Some of them date back to the 1980s and are still in use today, after more than 40 years. That’s why you should use the best practices of the time as a benchmark.
- You never know in advance how often a development will be corrected or expanded. A correction may not even be necessary because the development has an error, but simply because the execution environment has changed. The best example is the adjustments before switching to a HANA database.
- You often can’t estimate in advance how critical a development will be. A good example in this context are customer extensions. On the one hand, they allow processes to be customized, but on the other hand, they can also become central points of disruption for other processes.
- You don’t know who a development will influence. By that I mean who will learn from it and base their own ABAP development style on it because they have never seen anything else.
- A large proportion of the ABAP developments I have seen are of questionable quality. It simply cannot be any less. That was expressed very politely and kindly.
Unfortunately, low initial quality can have bad effects because of the points mentioned above. You get the feeling that such a development magically attracts problems, which are complicated to correct and extensions become daunting tasks. Only very experienced developers have the chance to make changes without negative side effects. My recommendation is therefore:
“Please do not sacrifice quality!”
The small exceptions
There are exceptions to the rule, but in very rare cases. For example, I immediately think of a small report for one-off corrections to data sets. This serves its purpose only once, and then it is useless. However, this form of correction reporting is rare.
It always starts somewhere
By the way, if you need to recall painful memories or an example where low initial quality subsequently led to Frankenstein’s monster reporting, the following lines are for you.
call method cl_salv_table=>factory
IMPORTING
R_SALV_TABLE = gr_table
changing
t_table = gt_outtab.
gr_table->display( ).Quality work must not be an exception
Michael