- SAP Managed Tags:
This week SAP picked a particularly thick wall to bang their heads against by advocating “pair programming” as an aid to unit testing and a generally good thing.
Dilbert Pair Programming
The first week in this course covered unit testing, which has a very low uptake indeed amongst ABAP programmers. The second week covered test driven developers which has a zero uptake amongst ABAP programmers. The third week covered pair programming which not only has a zero uptake amongst ABAP programmers but also they would all rather kill themselves than even consider the idea.
Can you spot a pattern forming here? As I understand it next week will cover the agile practice of bonding the development team by means of Morris Dancing.
This week however had two parts – the first was the aforementioned pair programming, the second was how to add new features to existing programs in a TDD / Unit Test type of way.
Part One – Pair Programming
It has been said that computer programmers prefer to work in small teams, preferably teams of one. That has certainly always been my experience.
This year I am going to be redesigning a huge program with a colleague and whilst we might be in the same room no-one ever suggested we sit at the same keyboard for a protracted period of time each day.
However that is just what pair programming is – two people sit together one is “the driver” and types the keys to write the code, one is the “navigator” and makes supposedly helpful suggestions. By this point you can see I am not being quite as positive as I have been in other blogs about this course.
You may wonder what pair programming has to do with unit testing at all. There are three possible answers:-
I’ll let you guess which of the three the correct answer is.
In any event the comedy double act pretty much instantly backed down and said you do not have to share a keyboard at all. Instead you can sit side by side and use your keyboard when it is your turn to type. Thank goodness for that, a huge weight off my shoulders.
The example they gave was one developer writes the test and then the other one writes the implementation. As this cycle is supposed to be very short that means the gaps between pressing keys are fairly short as well. This is also a rather desperate attempt to tie two disparate topics together.
Now as the cartoon above says despite the fact that you might think two different people would do more work on their own and the same two people sitting together many studies have found it increases productivity. Many other programmers have also claimed they have grown to like the idea.
Trying to keep an open mind for the moment, here are some actual reasons why this might actually be a good thing:-
Nonetheless, I think that managers may feel it halves productivity, and that most developers don’t fancy the idea, and if both the boss and the staff don’t want to do something that makes it pretty much a non-starter.
Perception of Pair Programming
Part Two – Adding New Features to Legacy Code
Here I should mention they take the definition of “Legacy Code” from Michael Feathers which is as follows.
Legacy Code = Code without Tests.
This of course is the situation most people find themselves in. For every hour we spend creating new programs we spend ten hours fixing and improving existing programs (at least in reasonable mature systems). Since we had never even heard of unit testing when we wrote those ten or fifteen years’ worth of programs none of them have tests, so they are all legacy code by this definition.
There are two situations mentioned by the double act – the first is when you want to make a small change to something existing, the second when you want to add a whole new piece of functionality.
For the first situation this was deemed out of scope, and the viewers were direct to Michael Feathers book “Working with Legacy Code”. As a disclaimer I have actually talked to Michael Feathers on the phone, at one point I was hoping to be assisting him with a training course he was going to be doing to a bank in Australia (I was going to be adapting his examples into ABAP) but the bank got cold feet and it never happened. He did claim to have read my chapter on unit testing in “ABAP to the Future” (because (a) it is the free sample chapter and (b) we sent it to him) and afterwards told me I seemed to understand what tests were all about, which was a lot better than if he had bombarded me with a fifteen minute torrent of abuse.
So it is possible I am biased when I say that “Working with Legacy Code” is a very good book, and once again can be applied to ABAP even if all the examples are in Java. I wold say it is quite heavy going though, and you have to read it at least twice before it starts to make sense, as the bulk of it consists of explanations of various techniques like “replace banana with cucumber”. Each technique has plenty of code examples but the text constantly refers to other techniques further along in the book. You could of course jump ahead to see what that term means but the explanation of THAT term would refer to a dozen other terms so you could end up like a dog chasing your tail. What I did was on the first pass guess what the unknown terms meant, and the second pass made a lot more sense.
Talking about funny terms the SAP duo came up with one themselves which is “The Island of Happiness”. Your existing program (with no tests) is the mainland and your new piece of functionality (full of unit tests, developed via TDD) is the Island of Happiness, self-contained in the same way an island is self-contained by being surrounded by sea (Girt by Sea as we say in Australia). Then when you are sure your island works 100% (you can tell by the tests) you connect it to the island by a bridge or ferry or similar mechanism to stop the wto infecting each other with plague.
Here is a diagram which demonstrates this:-
Misery Island
In the above diagram the mainland represents the legacy program, the purple line is the existing program flow, and the dots are the interface between the existing code and your new “Island of Happiness”.
So developing news things that are 100% isolated is a new OO type of thing is it? Hang on, didn’t in about 2002 my company implement a whole new concrete testing system and have existing programs call the new functionality via function modules? Function modules are not as isolated as classes can be, but you are not running that much risk of an existing program breaking if suddenly it calls a new function module, especially as you have control of what data (if any) comes back. The structure of the calling program is not fundamentally modified.
Of course the function modules had no tests so they were not an “Island of Happiness” even f they were isolated.
Meaningful Example
One criticism levelled at Michael Feathers book and in fact at every single example on the internet about introducing tests into existing programs, is that all the examples presume the “legacy” program is already 100% object oriented.
This causes ABAP people to switch off instantly, as all our existing programs are almost totally procedural, and that situation is glossed over like it did not exist.
So naturally the example presented in this SAP course had the existing program comprising 99% of classes, with a DYNPRO stuck on the top, like the penguin in Wallace and Gromit sticking a rubber glove on his head to make himself look like a chicken. The only difference is in the latter case he managed to fool some people into thinking he was actually a chicken.
As an aside, all the videos start with the words “Agile Software Engineering” and so the example programs often contain the acronym ASE, as do the names of the examples.
All around my ASE, I wear the Blue Ribbon
The example here is the “ASE Shop”, Some interesting OO concepts are explored here, such as the “rules pattern” where instead of having a series of hard coded rules you abstract the processing to a rules engine, thus hiding the number of rules or even the source of the rules – often you have many sources, be they IMG configuration tables, Z configuration tables, ABAO routines, BRF+ rules or whatever.
Here is a blog on the subject:-
https://blogs.sap.com/2017/07/07/using-the-rules-pattern-to-improve-code-maintainability/
The rules in question were very like BRF+ rules (which of course can be the actual rules hidden behind the abstraction that is the rules pattern) in that they had start and end dates.
There was also an abstract class at the top of one the hierarchies for storing the shared code. I tend to stick an interface on top as well, but maybe that is overkill.
Random Musings
Jelana got puzzled the other day when the comedy duo used the term “code smell”. That comes from “Clean Code” and just means some element of the design of the code is non-optimal.
In the same way they used the term “backlog” this week – that comes from agile programming where you arrange the user requirements in order of importance, split them into “sprints” and then each week on your “burn down” chart you have the “backlog” of items which have not yet been actioned. If you have ever read the book “A Clockwork Orange” the characters in that talk in a similar form of slang.
There was a list of recommended prefixes for the variables as well:-
None for Local
G_ for static member variables
M_ for instance member variables
E_ for exporting
I_ for importing
C_ for changing
R_ for returning
Nothing too radical there, I just thought it was vaguely interesting that SAP now have a recommendation – they never did before. Also – is a static member variable global? What if you make it read only? Can it be made private?
Pear Programming
Summary
This week was all about pair programming – which I think it will be an uphill battle for SAP to convince anyone about this, and adding unit tests to existing programs.
I have not been anywhere near as upbeat about this week as I have been about the first two.
This is not to say I do not see merit in either of the concepts – it is just that I don’t think this week has made any real progress in pushing either of them forward.
Cheersy Cheers
Paul
Dilbert Pair Programming
The first week in this course covered unit testing, which has a very low uptake indeed amongst ABAP programmers. The second week covered test driven developers which has a zero uptake amongst ABAP programmers. The third week covered pair programming which not only has a zero uptake amongst ABAP programmers but also they would all rather kill themselves than even consider the idea.
Can you spot a pattern forming here? As I understand it next week will cover the agile practice of bonding the development team by means of Morris Dancing.
This week however had two parts – the first was the aforementioned pair programming, the second was how to add new features to existing programs in a TDD / Unit Test type of way.
Part One – Pair Programming
It has been said that computer programmers prefer to work in small teams, preferably teams of one. That has certainly always been my experience.
This year I am going to be redesigning a huge program with a colleague and whilst we might be in the same room no-one ever suggested we sit at the same keyboard for a protracted period of time each day.
However that is just what pair programming is – two people sit together one is “the driver” and types the keys to write the code, one is the “navigator” and makes supposedly helpful suggestions. By this point you can see I am not being quite as positive as I have been in other blogs about this course.
You may wonder what pair programming has to do with unit testing at all. There are three possible answers:-
- The words “pair programming” are an anagram of “unit testing” with some letters added and others taken out.
- Writing test code is so unpleasant that you need someone sitting beside you to make sure you do not leap out of your chair and throw yourself out of the window.
- The two concepts are utterly unrelated. They just happened to both be mentioned in “Clean Code” by Robert Martin.
I’ll let you guess which of the three the correct answer is.
In any event the comedy double act pretty much instantly backed down and said you do not have to share a keyboard at all. Instead you can sit side by side and use your keyboard when it is your turn to type. Thank goodness for that, a huge weight off my shoulders.
The example they gave was one developer writes the test and then the other one writes the implementation. As this cycle is supposed to be very short that means the gaps between pressing keys are fairly short as well. This is also a rather desperate attempt to tie two disparate topics together.
Now as the cartoon above says despite the fact that you might think two different people would do more work on their own and the same two people sitting together many studies have found it increases productivity. Many other programmers have also claimed they have grown to like the idea.
Trying to keep an open mind for the moment, here are some actual reasons why this might actually be a good thing:-
- When you pair an experienced programming with a new one, it is like a tradesman working with an apprentice, a proven method for learning.
- If you keep switching “partners” throughout the team, like a country and western dance, then everyone gets to be familiar with what everyone else is working on, so you never get the situation where someone goes on holiday and their program breaks down and no-one else has a clue how it works.
- With someone looking over your shoulder there is a lot less scope for day dreaming, or surfing the web, or extended lunch breaks, or not actually doing anything ever and outsourcing your programming to a programmer in a third world country (that actually happened).
- It stops people working from home (that is only a good thing from the point of view of some managers).
Nonetheless, I think that managers may feel it halves productivity, and that most developers don’t fancy the idea, and if both the boss and the staff don’t want to do something that makes it pretty much a non-starter.
Perception of Pair Programming
Part Two – Adding New Features to Legacy Code
Here I should mention they take the definition of “Legacy Code” from Michael Feathers which is as follows.
Legacy Code = Code without Tests.
This of course is the situation most people find themselves in. For every hour we spend creating new programs we spend ten hours fixing and improving existing programs (at least in reasonable mature systems). Since we had never even heard of unit testing when we wrote those ten or fifteen years’ worth of programs none of them have tests, so they are all legacy code by this definition.
There are two situations mentioned by the double act – the first is when you want to make a small change to something existing, the second when you want to add a whole new piece of functionality.
For the first situation this was deemed out of scope, and the viewers were direct to Michael Feathers book “Working with Legacy Code”. As a disclaimer I have actually talked to Michael Feathers on the phone, at one point I was hoping to be assisting him with a training course he was going to be doing to a bank in Australia (I was going to be adapting his examples into ABAP) but the bank got cold feet and it never happened. He did claim to have read my chapter on unit testing in “ABAP to the Future” (because (a) it is the free sample chapter and (b) we sent it to him) and afterwards told me I seemed to understand what tests were all about, which was a lot better than if he had bombarded me with a fifteen minute torrent of abuse.
So it is possible I am biased when I say that “Working with Legacy Code” is a very good book, and once again can be applied to ABAP even if all the examples are in Java. I wold say it is quite heavy going though, and you have to read it at least twice before it starts to make sense, as the bulk of it consists of explanations of various techniques like “replace banana with cucumber”. Each technique has plenty of code examples but the text constantly refers to other techniques further along in the book. You could of course jump ahead to see what that term means but the explanation of THAT term would refer to a dozen other terms so you could end up like a dog chasing your tail. What I did was on the first pass guess what the unknown terms meant, and the second pass made a lot more sense.
Talking about funny terms the SAP duo came up with one themselves which is “The Island of Happiness”. Your existing program (with no tests) is the mainland and your new piece of functionality (full of unit tests, developed via TDD) is the Island of Happiness, self-contained in the same way an island is self-contained by being surrounded by sea (Girt by Sea as we say in Australia). Then when you are sure your island works 100% (you can tell by the tests) you connect it to the island by a bridge or ferry or similar mechanism to stop the wto infecting each other with plague.
Here is a diagram which demonstrates this:-
Misery Island
In the above diagram the mainland represents the legacy program, the purple line is the existing program flow, and the dots are the interface between the existing code and your new “Island of Happiness”.
So developing news things that are 100% isolated is a new OO type of thing is it? Hang on, didn’t in about 2002 my company implement a whole new concrete testing system and have existing programs call the new functionality via function modules? Function modules are not as isolated as classes can be, but you are not running that much risk of an existing program breaking if suddenly it calls a new function module, especially as you have control of what data (if any) comes back. The structure of the calling program is not fundamentally modified.
Of course the function modules had no tests so they were not an “Island of Happiness” even f they were isolated.
Meaningful Example
One criticism levelled at Michael Feathers book and in fact at every single example on the internet about introducing tests into existing programs, is that all the examples presume the “legacy” program is already 100% object oriented.
This causes ABAP people to switch off instantly, as all our existing programs are almost totally procedural, and that situation is glossed over like it did not exist.
So naturally the example presented in this SAP course had the existing program comprising 99% of classes, with a DYNPRO stuck on the top, like the penguin in Wallace and Gromit sticking a rubber glove on his head to make himself look like a chicken. The only difference is in the latter case he managed to fool some people into thinking he was actually a chicken.
As an aside, all the videos start with the words “Agile Software Engineering” and so the example programs often contain the acronym ASE, as do the names of the examples.
All around my ASE, I wear the Blue Ribbon
The example here is the “ASE Shop”, Some interesting OO concepts are explored here, such as the “rules pattern” where instead of having a series of hard coded rules you abstract the processing to a rules engine, thus hiding the number of rules or even the source of the rules – often you have many sources, be they IMG configuration tables, Z configuration tables, ABAO routines, BRF+ rules or whatever.
Here is a blog on the subject:-
https://blogs.sap.com/2017/07/07/using-the-rules-pattern-to-improve-code-maintainability/
The rules in question were very like BRF+ rules (which of course can be the actual rules hidden behind the abstraction that is the rules pattern) in that they had start and end dates.
There was also an abstract class at the top of one the hierarchies for storing the shared code. I tend to stick an interface on top as well, but maybe that is overkill.
Random Musings
Jelana got puzzled the other day when the comedy duo used the term “code smell”. That comes from “Clean Code” and just means some element of the design of the code is non-optimal.
In the same way they used the term “backlog” this week – that comes from agile programming where you arrange the user requirements in order of importance, split them into “sprints” and then each week on your “burn down” chart you have the “backlog” of items which have not yet been actioned. If you have ever read the book “A Clockwork Orange” the characters in that talk in a similar form of slang.
There was a list of recommended prefixes for the variables as well:-
None for Local
G_ for static member variables
M_ for instance member variables
E_ for exporting
I_ for importing
C_ for changing
R_ for returning
Nothing too radical there, I just thought it was vaguely interesting that SAP now have a recommendation – they never did before. Also – is a static member variable global? What if you make it read only? Can it be made private?
Pear Programming
Summary
This week was all about pair programming – which I think it will be an uphill battle for SAP to convince anyone about this, and adding unit tests to existing programs.
I have not been anywhere near as upbeat about this week as I have been about the first two.
This is not to say I do not see merit in either of the concepts – it is just that I don’t think this week has made any real progress in pushing either of them forward.
Cheersy Cheers
Paul
8 Comments
