To Bombay
A Change Control Circus came
They brought an ABAP elephant
And Nellie was her name
One dark night
She slipped her legacy chain, and off she ran
To H. Island; bugs were never seen again
Table of Contents
1 – The World in General
2 - The ABAP World
3 – My World
Part One: The World in General: There’s an ABAP Elephant in the Room
As you may have noticed this year there has some sort of virus going around. Put another way probably the greatest global disaster since the second world war, and in 98% of countries it is getting worse every day.
What is notable about the human race however is the way it responds to disasters. You have no doubt heard the saying “necessity is the mother of invention” and in times of crisis often the pace of technological innovation goes up through the roof.
Two examples I can think of are the fact that by the end of the year one in seven cars in the EU will be electric in some form, and the almost weekly launches of radical new spacecraft. I cannot predict when and if electric cars will ever become the mainstream but if they do it won’t be because of drivers caring about the environment (nice as that would be) but rather because the technologically has advanced to the stage where such a car is (a) cheaper than a traditional car, (b) can go further than a traditional car before having to refuel and (c) takes less time to refuel than filling up a traditional car. To state the obvious you would not normally replace something you own with a product that was in any way worse than what you already had. However if the proposed replacement was better in every single way then you would be crazy not to replace your current (whatever it is) when it runs out with the better cheaper one.
With electric cars we have not got to that stage yet – many say that to get to that stage might be impossible, especially the rapid charging bit, this is a very emotive subject, but if it does happen (to state the obvious again) it will be because of rapid advances in technology.
In the same way, in information technology world the fact that the actual world is getting turned upside down by the plague has forced companies to bring forward IT projects they were sort of thinking about possibly doing in five years’ time to having to implement them right here and now in record time.
The analogy would be - at government level rather than company level - the disaster that was the second world war turning two things from dreams to reality – computers (Bletchley Park in the UK) and space travel (Werner Von Braun in Germany).
Because that sort of innovation is now happening across the board when (if) this crisis ends a lot of companies will have found themselves having moved forward five to ten years IT wise in only a one to two-year period. In other words the surviving companies will bounce back stronger than before.
Where I work (in the building materials industry) IT technology has always advanced very quickly but if I think about what has happened/will happen this year it is amazing, even by our standards.
What has been replaced/upgraded/introduced: -
Replacement of BW moving to BW4HANA
Replacement of the Expenses System (not with Concur!)
Replacement of the Optical Character Recognition system
Replacement of Office => Office 365
Replacement of video conferences to that took 70 minutes to get working in order to have a one-hour meeting with TEAMS Meetings. I now know what all the bedrooms of my co-workers look like. If I had said that even a few years ago you would have drawn a very different conclusion.
Introduction of Robotic Process Automation (not the SAP one!)
That is all I can think of off the top of my head. I am sure there is a lot more, possibly dozens of other things. The point is we are going gangbusters fast forward into the future and no doubt so are hundreds of companies all around the globe.
That is fantastic is it not? So what is the ABAP elephant in the room? I cannot help but notice that whilst all this high-tech bright future stuff is going on a bucket load of the core Z programs that are used by SAP customers all around the world - to run the most vital parts of their business - are still the same way to this day that they were written in the year 2000, all procedural DYNPRO monsters with all the business logic mixed with UI logic. They are written in what is known as “legacy code” and every day more legacy code is being written/added to all these SAP systems.
This brings us to part two – why would this vital code be classed as “Legacy Code” and why is it a problem?
oooooooooooooooooo...
oooooooooooooooooo...
BANG! BANG! BANG! BANG!
Nellie the elephant packed her trunk and
Said goodbye to the circus
Off she rode with a Trumpety Trump
Donald Trump
Nellie the elephant packed her trunk
And tumbled off to the Jungle
Off she rode with a Trumpety Trump
Donald Trump
Night by night, she did all her tests by hand
When Nellie was leading the big parade she looked
So proud and grand
No more Citrix for Nellie to PERFORM
They taught her how to do workflow and she took
The crowd by storm
Part Two: The ABAP World: There is an ABAP Elephant Under my Bed
“Here it comes – prepare for the worst! The Ugliest Code in the Universe!” – Elephant! (1989)
According to IT guru Michael Feathers the definition of “Legacy Code” is code without automated tests. In SAP world the framework for running automated tests is ABAP Unit. How much of your ABAP code has automated unit tests you can run at the press of a button after making every change? If the answer is “none at all” then you would be far from alone.
Why does this matter? Why waste your time writing automated unit tests to change your current “legacy” code into so called “real” code?
The answer is all to do with the pace of change. The speed of change was accelerating every year anyway – the current crisis just put the foot on the accelerator pedal. I saw a presentation the other day that noted that over the years the ideology of IT departments had moved from “never change a working system” to “make as many changes as you can as often as you can”. The idea being that you need to do the latter in order to stay competitive.
Let us say something changes in the market – it does not matter what. The CEO informs IT and says “The XYZ has changed, it is vital you change the following six areas of the SAP system in order for us to be able to respond to this XYZ change otherwise we will lose market share. Please make this a priority and have the changes working in production ASAP”.
What the CEO expects based on experience is that those changes will go to production in the next release – maybe in two months’ time, possibly a lot longer. What the CEO wants is for those changes to go to production tomorrow, or preferably by lunchtime today, in any event faster than the competition can make those changes. So ten seconds time would be good.
So – why I can’t just make a change to my program that takes me an hour and then press a button and send it to production straight away? Well first off my change might not work, and secondly my current change might break something else. It would be irresponsible to send something to production that may not work and/or may cause serious damage elsewhere, so the traditional solution has been a very large number of people spending a very large amount of time doing manual testing.
The problem is that changing area A of a program often breaks area B or area C all the way down to area Z and you just do not know what is going to break. Moreover systems have become so complicated it is just unfeasible to manually test every possible eventuality. As someone I asked about testing once put it “Your average car has hundreds of components in its engine. When we build a new “car” all that seems to be tested is the radio”.
Automated unit tests – as in ABAP unit – can never replace manual testing but they can certainly remove a lot of the “grunt work” and find low level bugs before the code leaves the development system. As Robert Martin puts it “QA should find nothing!”.
Amazon makes much of the fact that they put a change into production on average several times a second. Based on your experience of SAP systems you would therefore expect that their live system would be broken 100% of the time – but as you know it is not. If you went to buy something on Amazon and the platform malfunctioned you would be very surprised indeed – and yet if your SAP end users found a serious bug in production suddenly started happening after the quarterly release they would be really annoyed but not surprised in the least.
The question then becomes how can they (Amazon) be so sure their constant stream of changes will not break their live system? A ten-minute outage would probably cost them a million dollars. Automated unit tests are not the only reason they can make such a vast number of changes, but they do play a vital role.
With SAP maybe we do not have such lofty goals – instead of several changes a second to production maybe we can hope to move from three releases a year to six? Is one release a week a ridiculous thing to aim for?
As the very first step on that road it would be great if you had an automated test for every aspect (low level programming unit) of your vital ABAP programs, so you know if any of them break after a change to a seemingly unrelated area. Now comes the major stumbling block – 99.9% of your legacy code is written in such a way that it is totally untestable, because business logic is mixed with UI logic and database logic and all sorts of things.
To make the code testable you would have to change it, and that (changing code that currently works 100% correctly) is a horrible, horrible risk, and risks are what we are trying to avoid.
So it would seem that the only way you can reduce the risk of program changes breaking your system in the future is by making lots of “un-needed” changes (to make the code testable) now which may break the system.
That is a very difficult business case to make i.e. I would like to make some changes that will have no immediate benefit and will possibly break the live system, in order to prevent some unspecified future problems which may or may not occur. If you put it like that, your chances are not high of getting approval.
This seems like a “you can’t get there from here” problem. The risks involved in reducing risks are just far too high. So how do you square that circle? That brings us to part three.
oooooooooooooooooo...
oooooooooooooooooo...
BANG! BANG! BANG! BANG!
Nellie the elephant packed her trunk and
Said goodbye to the circus
Off she rode with a Trumpety Trump
Donald Trump
Nellie the elephant packed her trunk
And tumbled off to the jungle
Off she rode with a Trumpety Trump
Donald Trump
Part Three: My World: How can you tell if an ABAP Elephant has been in your fridge?
“Giant Footprints in the Butter!”
Just prior to the last burst of singing we were considering how to move from “Legacy Code” to a situation where all the code has automated tests – all without blowing up the entire universe in the process.
As it transpires this is exactly the sort of thing I have been working on in my day job for the last year or two. Right at the start of this blog you may have noticed in the introductory song that Nellie had ran away to “H. Island”. What is that you might ask? Why would an ABAP Elephant want to go to such a place?
“H. Island” stands for “Happiness Island”. The idea came from the Open SAP Course on Test Driven Development and revolves around adding all new code to old Z programs (or extracting any routine you need to change) into a new class which is developed via TDD and thus has 100% of its code subject to automated unit tests. You add in calls to the new happy code from your existing sad legacy code just like you were adding a new function module call, thus not having the risk of a major re-write of your existing code.
The idea is that as time goes by the Island gets bigger and the Mainland (huge legacy code program) gets smaller but the end user does not notice anything except that the time between asking for something new and getting something new decreases.
Was this some sort of esoteric academic new theory? Possibly yes. Have I been doing it in real life? Yes I have. Does it work? Yes it does. Therefore it has been proven (by me and hopefully by lots of other people) that it is possible to make your vital Z programs better with every change as opposed to worse. What I mean by the latter is traditionally with every change you make to the program not only might that new change break something but even after it works the fact that the program is now more complex has increased the risk of every subsequent change breaking it i.e. it gets more fragile with time. This can be turned upon its head.
Naturally that is easier said than done – what you would ideally like is some sort of detailed step by step guide on how precisely to go about this exercise, rather than having to work it out yourself by trial and error
I have been blogging about this sort of thing on SCN (I still call it SCN, I do not hold with the SAP concept of renaming every single thing every single week) for many years. As a starting point you really need to program using OO. If you don’t know what that stands for then, oh dear. The OO version of ABAP was introduced in 2000 but even now many ABAP programmers cannot see the need/purpose.
I tried to approach the subject with an open mind and only after a vast amount of experiments -which I documented via SCN blogs – did I conclude that OO is the way to go. I concluded it is a good thing in and of itself (not just become someone said so but from real life experience).
For example
https://blogs.sap.com/2012/10/27/crossing-the-great-divide-procedural-vs-oo-abap-programming/
If OO is the starting point there is a next level. If it is true (and sadly it is) that even after 20 years hardly anyone writes in an OO manner in ABAP then of that small percentage only a small fraction of that small fraction use automated unit tests. Thus I have blogged about that as well.
For example
https://blogs.sap.com/2018/04/21/sap-open-course-unit-testing-week-6-working-with-existing-code/
Both sets of blogs are – in effect - all about getting Nellie the ABAP Elephant away from the Legacy Circus and onto Happiness Island.
Whilst we are on the subject of SCN blogs, you won’t have seen very many blogs from me on SCN this year, but just as work has gotten loony busy this year, so has the amount of SAP things I have been doing in my spare time have exploded just as exponentially as the worky SAP things have.
So, as you will have just gathered, this whole blog is in fact just a plug for my new book! Ha Ha Ha! A-Ha Ha Ha! HA HA HA HA HA!
Once upon a time that would not have been allowed to publish such a shameless plug on the SCN site… but now the moderators tell me I can plug whatever I want. That makes me want to sing – SING – SING!
oooooooooooooooooo...
oooooooooooooooooo...
BANG! BANG! BANG! BANG!
Nellie the elephant packed her trunk and
Said goodbye to the circus
Off she rode with a Trumpety Trump
Donald Trump
Nellie the elephant packed her trunk
And tumbled off to the jungle
Off she rode with a Trumpety Trump
Donald Trump
The head of the herd was fed up – Leg, Legacy
So they meet one night in Microsoft Silverlight
On the road to TDD
Nellie the elephant packed her trunk
And tumbled off to the jungle
Off she rode with a Trumpety Trump
Trump! TRUMP! TRUMP!
1956 Version
https://www.youtube.com/watch?v=28Rh9zRdXxA
1984 Version
https://www.youtube.com/watch?v=9m7tPikH0UA
Plug
https://bit.ly/34ftbYj
Coupon code – RLAC10
The coupon code provides customers with a 10% discount when they purchase the E-Bite from the SAP PRESS site.
Cheersy Cheers
Paul
A Change Control Circus came
They brought an ABAP elephant
And Nellie was her name
One dark night
She slipped her legacy chain, and off she ran
To H. Island; bugs were never seen again
Nellie#1
Table of Contents
1 – The World in General
2 - The ABAP World
3 – My World
Part One: The World in General: There’s an ABAP Elephant in the Room
As you may have noticed this year there has some sort of virus going around. Put another way probably the greatest global disaster since the second world war, and in 98% of countries it is getting worse every day.
What is notable about the human race however is the way it responds to disasters. You have no doubt heard the saying “necessity is the mother of invention” and in times of crisis often the pace of technological innovation goes up through the roof.
Two examples I can think of are the fact that by the end of the year one in seven cars in the EU will be electric in some form, and the almost weekly launches of radical new spacecraft. I cannot predict when and if electric cars will ever become the mainstream but if they do it won’t be because of drivers caring about the environment (nice as that would be) but rather because the technologically has advanced to the stage where such a car is (a) cheaper than a traditional car, (b) can go further than a traditional car before having to refuel and (c) takes less time to refuel than filling up a traditional car. To state the obvious you would not normally replace something you own with a product that was in any way worse than what you already had. However if the proposed replacement was better in every single way then you would be crazy not to replace your current (whatever it is) when it runs out with the better cheaper one.
With electric cars we have not got to that stage yet – many say that to get to that stage might be impossible, especially the rapid charging bit, this is a very emotive subject, but if it does happen (to state the obvious again) it will be because of rapid advances in technology.
In the same way, in information technology world the fact that the actual world is getting turned upside down by the plague has forced companies to bring forward IT projects they were sort of thinking about possibly doing in five years’ time to having to implement them right here and now in record time.
The analogy would be - at government level rather than company level - the disaster that was the second world war turning two things from dreams to reality – computers (Bletchley Park in the UK) and space travel (Werner Von Braun in Germany).
Because that sort of innovation is now happening across the board when (if) this crisis ends a lot of companies will have found themselves having moved forward five to ten years IT wise in only a one to two-year period. In other words the surviving companies will bounce back stronger than before.
Where I work (in the building materials industry) IT technology has always advanced very quickly but if I think about what has happened/will happen this year it is amazing, even by our standards.
What has been replaced/upgraded/introduced: -
Replacement of BW moving to BW4HANA
Replacement of the Expenses System (not with Concur!)
Replacement of the Optical Character Recognition system
Replacement of Office => Office 365
Replacement of video conferences to that took 70 minutes to get working in order to have a one-hour meeting with TEAMS Meetings. I now know what all the bedrooms of my co-workers look like. If I had said that even a few years ago you would have drawn a very different conclusion.
Introduction of Robotic Process Automation (not the SAP one!)
That is all I can think of off the top of my head. I am sure there is a lot more, possibly dozens of other things. The point is we are going gangbusters fast forward into the future and no doubt so are hundreds of companies all around the globe.
That is fantastic is it not? So what is the ABAP elephant in the room? I cannot help but notice that whilst all this high-tech bright future stuff is going on a bucket load of the core Z programs that are used by SAP customers all around the world - to run the most vital parts of their business - are still the same way to this day that they were written in the year 2000, all procedural DYNPRO monsters with all the business logic mixed with UI logic. They are written in what is known as “legacy code” and every day more legacy code is being written/added to all these SAP systems.
This brings us to part two – why would this vital code be classed as “Legacy Code” and why is it a problem?
oooooooooooooooooo...
oooooooooooooooooo...
BANG! BANG! BANG! BANG!
Nellie the elephant packed her trunk and
Said goodbye to the circus
Off she rode with a Trumpety Trump
Donald Trump
Nellie the elephant packed her trunk
And tumbled off to the Jungle
Off she rode with a Trumpety Trump
Donald Trump
Nellie#2
Night by night, she did all her tests by hand
When Nellie was leading the big parade she looked
So proud and grand
No more Citrix for Nellie to PERFORM
They taught her how to do workflow and she took
The crowd by storm
Part Two: The ABAP World: There is an ABAP Elephant Under my Bed
“Here it comes – prepare for the worst! The Ugliest Code in the Universe!” – Elephant! (1989)
According to IT guru Michael Feathers the definition of “Legacy Code” is code without automated tests. In SAP world the framework for running automated tests is ABAP Unit. How much of your ABAP code has automated unit tests you can run at the press of a button after making every change? If the answer is “none at all” then you would be far from alone.
Why does this matter? Why waste your time writing automated unit tests to change your current “legacy” code into so called “real” code?
The answer is all to do with the pace of change. The speed of change was accelerating every year anyway – the current crisis just put the foot on the accelerator pedal. I saw a presentation the other day that noted that over the years the ideology of IT departments had moved from “never change a working system” to “make as many changes as you can as often as you can”. The idea being that you need to do the latter in order to stay competitive.
Let us say something changes in the market – it does not matter what. The CEO informs IT and says “The XYZ has changed, it is vital you change the following six areas of the SAP system in order for us to be able to respond to this XYZ change otherwise we will lose market share. Please make this a priority and have the changes working in production ASAP”.
What the CEO expects based on experience is that those changes will go to production in the next release – maybe in two months’ time, possibly a lot longer. What the CEO wants is for those changes to go to production tomorrow, or preferably by lunchtime today, in any event faster than the competition can make those changes. So ten seconds time would be good.
So – why I can’t just make a change to my program that takes me an hour and then press a button and send it to production straight away? Well first off my change might not work, and secondly my current change might break something else. It would be irresponsible to send something to production that may not work and/or may cause serious damage elsewhere, so the traditional solution has been a very large number of people spending a very large amount of time doing manual testing.
The problem is that changing area A of a program often breaks area B or area C all the way down to area Z and you just do not know what is going to break. Moreover systems have become so complicated it is just unfeasible to manually test every possible eventuality. As someone I asked about testing once put it “Your average car has hundreds of components in its engine. When we build a new “car” all that seems to be tested is the radio”.
Automated unit tests – as in ABAP unit – can never replace manual testing but they can certainly remove a lot of the “grunt work” and find low level bugs before the code leaves the development system. As Robert Martin puts it “QA should find nothing!”.
Amazon makes much of the fact that they put a change into production on average several times a second. Based on your experience of SAP systems you would therefore expect that their live system would be broken 100% of the time – but as you know it is not. If you went to buy something on Amazon and the platform malfunctioned you would be very surprised indeed – and yet if your SAP end users found a serious bug in production suddenly started happening after the quarterly release they would be really annoyed but not surprised in the least.
The question then becomes how can they (Amazon) be so sure their constant stream of changes will not break their live system? A ten-minute outage would probably cost them a million dollars. Automated unit tests are not the only reason they can make such a vast number of changes, but they do play a vital role.
With SAP maybe we do not have such lofty goals – instead of several changes a second to production maybe we can hope to move from three releases a year to six? Is one release a week a ridiculous thing to aim for?
As the very first step on that road it would be great if you had an automated test for every aspect (low level programming unit) of your vital ABAP programs, so you know if any of them break after a change to a seemingly unrelated area. Now comes the major stumbling block – 99.9% of your legacy code is written in such a way that it is totally untestable, because business logic is mixed with UI logic and database logic and all sorts of things.
To make the code testable you would have to change it, and that (changing code that currently works 100% correctly) is a horrible, horrible risk, and risks are what we are trying to avoid.
So it would seem that the only way you can reduce the risk of program changes breaking your system in the future is by making lots of “un-needed” changes (to make the code testable) now which may break the system.
That is a very difficult business case to make i.e. I would like to make some changes that will have no immediate benefit and will possibly break the live system, in order to prevent some unspecified future problems which may or may not occur. If you put it like that, your chances are not high of getting approval.
This seems like a “you can’t get there from here” problem. The risks involved in reducing risks are just far too high. So how do you square that circle? That brings us to part three.
oooooooooooooooooo...
oooooooooooooooooo...
BANG! BANG! BANG! BANG!
Nellie the elephant packed her trunk and
Said goodbye to the circus
Off she rode with a Trumpety Trump
Donald Trump
Nellie the elephant packed her trunk
And tumbled off to the jungle
Off she rode with a Trumpety Trump
Donald Trump
Nellie#3
Code Cleaning Device
Part Three: My World: How can you tell if an ABAP Elephant has been in your fridge?
“Giant Footprints in the Butter!”
Just prior to the last burst of singing we were considering how to move from “Legacy Code” to a situation where all the code has automated tests – all without blowing up the entire universe in the process.
As it transpires this is exactly the sort of thing I have been working on in my day job for the last year or two. Right at the start of this blog you may have noticed in the introductory song that Nellie had ran away to “H. Island”. What is that you might ask? Why would an ABAP Elephant want to go to such a place?
“H. Island” stands for “Happiness Island”. The idea came from the Open SAP Course on Test Driven Development and revolves around adding all new code to old Z programs (or extracting any routine you need to change) into a new class which is developed via TDD and thus has 100% of its code subject to automated unit tests. You add in calls to the new happy code from your existing sad legacy code just like you were adding a new function module call, thus not having the risk of a major re-write of your existing code.
The idea is that as time goes by the Island gets bigger and the Mainland (huge legacy code program) gets smaller but the end user does not notice anything except that the time between asking for something new and getting something new decreases.
Was this some sort of esoteric academic new theory? Possibly yes. Have I been doing it in real life? Yes I have. Does it work? Yes it does. Therefore it has been proven (by me and hopefully by lots of other people) that it is possible to make your vital Z programs better with every change as opposed to worse. What I mean by the latter is traditionally with every change you make to the program not only might that new change break something but even after it works the fact that the program is now more complex has increased the risk of every subsequent change breaking it i.e. it gets more fragile with time. This can be turned upon its head.
Naturally that is easier said than done – what you would ideally like is some sort of detailed step by step guide on how precisely to go about this exercise, rather than having to work it out yourself by trial and error
I have been blogging about this sort of thing on SCN (I still call it SCN, I do not hold with the SAP concept of renaming every single thing every single week) for many years. As a starting point you really need to program using OO. If you don’t know what that stands for then, oh dear. The OO version of ABAP was introduced in 2000 but even now many ABAP programmers cannot see the need/purpose.
I tried to approach the subject with an open mind and only after a vast amount of experiments -which I documented via SCN blogs – did I conclude that OO is the way to go. I concluded it is a good thing in and of itself (not just become someone said so but from real life experience).
For example
https://blogs.sap.com/2012/10/27/crossing-the-great-divide-procedural-vs-oo-abap-programming/
If OO is the starting point there is a next level. If it is true (and sadly it is) that even after 20 years hardly anyone writes in an OO manner in ABAP then of that small percentage only a small fraction of that small fraction use automated unit tests. Thus I have blogged about that as well.
For example
https://blogs.sap.com/2018/04/21/sap-open-course-unit-testing-week-6-working-with-existing-code/
Both sets of blogs are – in effect - all about getting Nellie the ABAP Elephant away from the Legacy Circus and onto Happiness Island.
Whilst we are on the subject of SCN blogs, you won’t have seen very many blogs from me on SCN this year, but just as work has gotten loony busy this year, so has the amount of SAP things I have been doing in my spare time have exploded just as exponentially as the worky SAP things have.
- In February 2020 I published an e-learning course all about Test Driven Development on a platform called “Michael Management”.
- I was due to give three presentations in the “Mastering SAP Technologies” event in South Africa in March 2020.The in-person event was cancelled at the last minute due to virus concerns, but the conference ended up happening virtually – so I gave two speeches just last week.
- In April 2020 there was the fantastic virtual event “SAP Online Track” which ran for 24 hours and was sort of like an SAP “Live Aid” event in that it raised money for a charity “Girls Who Code”. I was very happy to be able to do a presentation during that event.
- In May 2020 I had a so called “E-Bite” published by SAP Press which was all about how to migrate custom code to S/4HANA - https://www.youtube.com/watch?v=ebbTDNuJf8A&feature=youtu.be
- Ever since June 2020 I have been writing a book all about increasingly the quality of ABAP code, incorporating some parts/concepts from the SCN blogs I have written over the years, but mainly using a bucket load of actual examples I have encountered in real life over the years. This is the opposite of “ABAP to the Future” in that it is focused on code written in the past. This has been really brutal, it has been like having to write two or three blogs a week, every week.
- In September 2020 I did a live Q&A about all things ABAP for the Michael Management company - https://www.youtube.com/watch?v=EyvEKww2kXk
- This month – October 2020 – on the 21st of October 2020 – I have another SAP Press E-Bite coming out; this time called “Refactoring Legacy Code” – link at the end of the blog -which is based on what I have been doing in real life recently in this regard i.e. what I just talked about in the third section of this blog. The book is a step by step guide how to change a monstrous legacy ABAP program into a modern OO program with automated tests in a safe manner using the “Island of Happiness” approach.
So, as you will have just gathered, this whole blog is in fact just a plug for my new book! Ha Ha Ha! A-Ha Ha Ha! HA HA HA HA HA!
Nellie#4
Once upon a time that would not have been allowed to publish such a shameless plug on the SCN site… but now the moderators tell me I can plug whatever I want. That makes me want to sing – SING – SING!
oooooooooooooooooo...
oooooooooooooooooo...
BANG! BANG! BANG! BANG!
Nellie the elephant packed her trunk and
Said goodbye to the circus
Off she rode with a Trumpety Trump
Donald Trump
Nellie the elephant packed her trunk
And tumbled off to the jungle
Off she rode with a Trumpety Trump
Donald Trump
The head of the herd was fed up – Leg, Legacy
So they meet one night in Microsoft Silverlight
On the road to TDD
Nellie the elephant packed her trunk
And tumbled off to the jungle
Off she rode with a Trumpety Trump
Trump! TRUMP! TRUMP!
1956 Version
https://www.youtube.com/watch?v=28Rh9zRdXxA
1984 Version
https://www.youtube.com/watch?v=9m7tPikH0UA
Plug
https://bit.ly/34ftbYj
Coupon code – RLAC10
The coupon code provides customers with a 10% discount when they purchase the E-Bite from the SAP PRESS site.
Cheersy Cheers
Paul
- SAP Managed Tags:
21 Comments
