When you finish writing a new ABAP program it starts off as a thing of beauty. It does the one thing it was designed to do (e.g. list sales orders) very well indeed in an elegant fashion and you are incredibly happy with the quality and simplicity of your code.
Then the problems start. One of my favorite sayings is “no battle plan survives contact with the enemy” and in this case as soon as real human beings (the so-called “end users”) start to use your wonderful program in will come the change requests.
“Can we have an extra field here? Just one”.
“How about an extra selection option? Just one”.
“How about adding a calculated field? Just one. Oh and by the way make that other field editable”.
Before you know it your simple program has become a 60,000 line monster which has become business-critical whilst at the same time becoming so complicated nobody can understand it. All the changes were done by different people, in a hurry every time.
You are now in a horrible vicious circle. The more business-critical the program becomes, the more change requests and extra functionality come in, which makes it, even more, business-critical, leading to even more requests and so on forever.
Worse with every change the program becomes more unstable and the risk of causing something that currently works to stop working steadily rises until the probability of breaking something each time hits 100%.
You think things cannot possibly get any worse but yes they can.
In mythology, there was a sort of Dragon called a Hydra. If you cut off one of its heads then another seven would grow in its place. Programs get like that. Your latest change has a horrible side effect, you fix that side effect, and seven more side effects pop up, and so on ad infinitum.
Now you are at the stage that when a new change request comes your way, you start screaming and cannot stop. You may have heard the phrase “the worst sort of nightmare is the type that happens when you are awake”.
For example, the guy who sat in the corner of our office was the sole developer for a program such as the one I have just described, and every morning after the changes had gone into production, he would get a queue of business analysts from his desk out the office door and halfway down the corridor - each one with a list of all the problems the business users in the country they looked after had found.
Would you want to come to work that day knowing that would be waiting for you? It’s no fun for the developer, it’s no fun for management, and it’s certainly no fun for the end-users.
So what do people do to fight against this?
There are multiple approaches to solving this problem, some more effective than others.
This is not a replacement for all the approaches named above – e.g. manual testing, automated testing frameworks, ensuring code quality – but rather something complimentary which means there are far fewer errors in the first place. Strangely enough, it cannot stop people from making errors, but it can make them more obvious once they are there.
When I tell some management people that TDD involves automated regression tests using the (free) unit testing framework within the ABAP language they often say “But I have just paid XXXX dollars for HPQC why do I need another automated testing framework?”
To answer that I have come up with a grid to explain the difference between ABAP Unit (as used by TDD) and HPQC (and similar frameworks).
Table Created by MMC Instructor, Paul Hardy
BSA stands for “Business Systems Analyst”. The focus of ABAP Unit (which enables TDD) is different from the focus of tools like HPQC. I liken TDD to testing every component of a machine before it is assembled, HPQC is doing thousands of automated tests on the finished product, and then it would be a really good idea to have humans’ do a bit of manual testing as well.
The problem I have been discussing is the tendency for programs to get more “brittle” over time and become subject to unexpected errors whenever changed. I then noted some common techniques for trying to find those errors before the changes hit production.
However, the best way to deal with a problem is not to have that problem occur in the first place. My message to the world is that you write your program or make your changes using TDD then the program gets stronger with each change, not weaker. To this end, I created an ABAP course on Michael Management all about TDD which I encourage you to investigate.