- SAP Managed Tags:
The Amityville Programming Horror
Can an old program be so monstrous and scary, you are terrified to change it?
This fine day, I was asked to add some new functionality to a program I had written back in the year 2000.
I instantly started screaming and threatening to throw myself off the bridge, and begged “please lord, not me, why me”. I mustered all the arguments I could why this program should not have the extra functionality added including “it’s suffered enough”, and suggested creating a new program to address the new business problem specifically.
All to no avail.
A new business problem had to be solved; the current program did most of it, just “one wafer thin mint” of functionality needed to be added to the “Mr. Creosote” of a program and I was the lucky programmer to have to do this, as I wrote the thing in the first place.
Anyone who has seen Monty Pythons “The Meaning of Life” would know why I did not want to add the wafer thin mint to the program. The question is – why was I so perturbed? Changing programs is my job is it not? I change other programs every day, why was I so terrified of this one that I would hide under my bed rather than go near it?
Moreover this is not some interactive program that updates dozens of tables at once. It is a read only ALV report. What could possibly be scary about that?
In the same way the original “Muppet Movie” had the tag line “You will believe a Frog can ride a Bicycle” I would say “You will believe a simple report can be mutated into a Demon from Hell”.
Naturally I am going to mask my actual day to day work by pretending I am working on monster related programs for Baron Frankenstein, but nonetheless, this is something actually happening to me in real life.
Back in the year 2000 at the start of the SAP project I realised there was no standard SAP report to display shipment costs (for transporting monsters) from table VFKP in a way that made any sense to a human.
So I wrote a really simple ALV report doing a join on tables LIKP/LIPS/VTTK/VFKP and it was so simple, it ran like lightning and all the useful information was there. One of the evil scientists took one look at the report and said ‘you can run your business using this’. I was so happy, so proud, and it had all been so easy.
Then the so called “Venus De Milo” problem started (warning – link contains a rude word).
http://koldfront.dk/archive/2004/03/30-173627.html
After the report was created about every six months, on average, another table or two are added to the data retrieval, until the report gradually becomes all things to all people. With each addition it runs slower, of course.
In about 2001 a senior Mad Scientist complained that this report had become bloated with a load of weirdo requests, and he demanded that going forward all such requests had to be routed through him for approval first. That did not make as much difference as he had hoped, since all the so called weirdo requests had actually come from him in the first place, he had forgotten he had made them.
Anyway he moved on, but the weirdo request never stopped as the years went by. Every time the change was made by a different programmer, each time they added the new functionality where it seemed a good place to put it, often in a routine that previously did something utterly unrelated.
Recently there was an idea to add in lots of extra - let us call it Hunchback - information, and this (Hunchback information) now accounts for 33% of the processing time, and people are moaning about the hugely expanded runtime before they see a result.
The program has gradually lost all structure over time - both internally, and in a business sense in regard to what it is perceived to be used for by the users - and in the words of programming guru Robert C. Martin it has “rotted like a piece of meat”.
So before I delve into this monstrosity to make the new changes, to get a baseline before I make those changes I go into production, run the report and do an SQL trace using ST05.
After staring at the results in amazed horror, and crying tears of outrage at the horrible “thing” the masterpiece I created has become, I concluded that as I have to change it anyway I feel a burning desire to mop up some of the open sores that are oozing programming pus all over the place, to counteract the fact I am adding to the problem by adding even more functionality in.
Hopefully I will be able to follow another of Robert Martins rules, the “Boy Scout Rule” where you leave the campground cleaner than you found it.
In subsequent blogs I am going to into detail as to how I clean this monstrosity up step by step.
So stay posted….
Cheersy Cheers
Paul
Can an old program be so monstrous and scary, you are terrified to change it?
This fine day, I was asked to add some new functionality to a program I had written back in the year 2000.
I instantly started screaming and threatening to throw myself off the bridge, and begged “please lord, not me, why me”. I mustered all the arguments I could why this program should not have the extra functionality added including “it’s suffered enough”, and suggested creating a new program to address the new business problem specifically.
All to no avail.
A new business problem had to be solved; the current program did most of it, just “one wafer thin mint” of functionality needed to be added to the “Mr. Creosote” of a program and I was the lucky programmer to have to do this, as I wrote the thing in the first place.
Anyone who has seen Monty Pythons “The Meaning of Life” would know why I did not want to add the wafer thin mint to the program. The question is – why was I so perturbed? Changing programs is my job is it not? I change other programs every day, why was I so terrified of this one that I would hide under my bed rather than go near it?
Moreover this is not some interactive program that updates dozens of tables at once. It is a read only ALV report. What could possibly be scary about that?
In the same way the original “Muppet Movie” had the tag line “You will believe a Frog can ride a Bicycle” I would say “You will believe a simple report can be mutated into a Demon from Hell”.
Naturally I am going to mask my actual day to day work by pretending I am working on monster related programs for Baron Frankenstein, but nonetheless, this is something actually happening to me in real life.
Back in the year 2000 at the start of the SAP project I realised there was no standard SAP report to display shipment costs (for transporting monsters) from table VFKP in a way that made any sense to a human.
So I wrote a really simple ALV report doing a join on tables LIKP/LIPS/VTTK/VFKP and it was so simple, it ran like lightning and all the useful information was there. One of the evil scientists took one look at the report and said ‘you can run your business using this’. I was so happy, so proud, and it had all been so easy.
Then the so called “Venus De Milo” problem started (warning – link contains a rude word).
http://koldfront.dk/archive/2004/03/30-173627.html
After the report was created about every six months, on average, another table or two are added to the data retrieval, until the report gradually becomes all things to all people. With each addition it runs slower, of course.
In about 2001 a senior Mad Scientist complained that this report had become bloated with a load of weirdo requests, and he demanded that going forward all such requests had to be routed through him for approval first. That did not make as much difference as he had hoped, since all the so called weirdo requests had actually come from him in the first place, he had forgotten he had made them.
Anyway he moved on, but the weirdo request never stopped as the years went by. Every time the change was made by a different programmer, each time they added the new functionality where it seemed a good place to put it, often in a routine that previously did something utterly unrelated.
Recently there was an idea to add in lots of extra - let us call it Hunchback - information, and this (Hunchback information) now accounts for 33% of the processing time, and people are moaning about the hugely expanded runtime before they see a result.
The program has gradually lost all structure over time - both internally, and in a business sense in regard to what it is perceived to be used for by the users - and in the words of programming guru Robert C. Martin it has “rotted like a piece of meat”.
So before I delve into this monstrosity to make the new changes, to get a baseline before I make those changes I go into production, run the report and do an SQL trace using ST05.
After staring at the results in amazed horror, and crying tears of outrage at the horrible “thing” the masterpiece I created has become, I concluded that as I have to change it anyway I feel a burning desire to mop up some of the open sores that are oozing programming pus all over the place, to counteract the fact I am adding to the problem by adding even more functionality in.
Hopefully I will be able to follow another of Robert Martins rules, the “Boy Scout Rule” where you leave the campground cleaner than you found it.
In subsequent blogs I am going to into detail as to how I clean this monstrosity up step by step.
So stay posted….
Cheersy Cheers
Paul
2 Comments
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
