ABAP – The Special Snowflake
ABAP – The Special Snowflake
The other day I poked the bear. Bears for the most part are things that should be left to their own devices as my Canadian friends will attest.
The bear in this case was Dennis Howlett who has been a long time friend in the enterprisey space
I met back as part of the media and influencers team at Sapphire and Teched events around 2006.
Dennis was asking about the new ESME as part of a conversation about Diversity amoungst the SAP Mentors. (That is a blog for another day)
And where is the next #ESME team coming from?
— (((Den Howlett))) (@dahowlett) June 21, 2018
I replied:
#abapgit is the biggest non sap led thing happening in SAP
Cc @LarsHvam
— Nigel James (@njames) June 23, 2018
Now for background #ESME was a Enterprise Social Media Experiment that happened around 2006-7ish and could have been something cool. It became an apache project which was qudos to the people driving it https://esme.apache.org/.
So Den was asking about what the new cool edgy thing was around SAP these days. As I said in my tweet above it is my opinion that that is #AbapGit with a whole lot of whitespace until second.
Then (which is what I was hoping would happen ) Den looked into #AbapGit and dropped the following:
Earlier today I took a look at #abapgit. It is seriously good stuff. The tragedy is that VERY few @SAPMentors or others are committers in the context of the #SAP ecosystem. Shout out to @grahamrobbo for waving the flag as vigorously as possible. cc @njames for poking me on this.
— (((Den Howlett))) (@dahowlett) June 28, 2018
The conversation that followed continued on for days across timezones picking up a whole lot of other voices and opinions on the way through.
My attempt with this blog is to try and bring some of those opinions into one place and simulate the conversation further as to what sort of innovation we are looking for around the SAP technology space. And if you are short on time here is the tl;dr:
- ABAP has legacy tools
- ABAP has legacy culture
- It is stuck there and will never ever move
- ABAPGit is the best thing that happened to the ABAP ecosystem since ABAPUnit
- Adoption of both of these toolsets are woefully low (Please see point 2.)
- These are exactly the tools that we need to create CI/CD platforms for SAP landscapes.
There. If you want to skip to the next blog… go for it but first identify what culture is happening amongst your ABAPers or your offshore team.
If you want to enjoy the rest of the story then fasten your seat belts, return your tray table to the upright position and hold on.
#Disclaimer
Let me provide a disclaimer for those that love ABAP to a fault ( Hi Michelle, Hi Jellana ). Yes, ABAP is awesome and yes is does power half the planet if you believe SAP’s marketing department but being great is not enough – all languages need to improve and get better.
Am you saying that ABAP is not doing this? I mean that is a pretty provocative, click-baity title you put on this blog there Nigel.
Yes it is provocative and no – ABAP is innovating ( Hi Horst ) There are incredibly talentent people inside and outside SAP pushing to improve the language, toolset and culture to become the best that is can be and when they are finished they will go some more.
The problem is that good ol’ ABAP is for all intents closed source prorietory language. My other two favourite languages that include the letter P ( Python and PHP ) are not. They have continually innovated around their core. Just the other day I saw Zeev Suraski one of the co-architects of PHP saying that the next release of PHP would be 4-5 times faster than version 7. This is not bad given that version 7 was twice as fast as version 5.x that preceeded it.
What languages carry with them – more than anything else is legacy baggage. PHP certainly does – and routinely get bagged for it but many companies including Facebook, Slack, and Mailchimp have PHP at the heart of their business and serve many millions of customers. Enterprisey enought for you? ABAP, coming from its FORTRAN and COBOL roots has a very verbose nature and weird keywords. That’s why we “love” it right? Many improvements over the years have been welcome and the code we write in ABAP today is not the code we wrote 20 years ago.
What they also bring is toolsets, “tecosystems” ( Thanks @sogrady ) and a culture that grows up around them.
#ABAPGit can shift the ABAP CI landscape
My thesis in this twitter thread that developed was that #ABAPGit could bring new ways of deploying code to the ABAP Ecosystem just as #UI5 has brought innovation to the Front End and HANA has brought innovation to the database.
Mindsets like ‘caching’ tables to hold monthly summarys that are no longer needed in S4/HANA. If they can innovate around the DB and drop tables why not around CI/CD and ditch STMS? @BoobBoo – your turn to pitch in 🙂
— Nigel James (@njames) June 28, 2018
Other believe the culture needs to come first:
Just quickly chime in here and posit that tooling is not the biggest reason #sap customers don’t deploy multiple times a day. Tooling certainly helps – but the “enterprise” mindset that has formed over 30+ years is really hard to break down
— Graham Robinson (@grahamrobbo) June 28, 2018
Graham is right though. Enterprise mindset is hard to break down.
In other development enviroments the deploy to prod as often as required is commonplace. When I gave a talk about learning #git back at #SAPTeched in 2015 I had a guy from Github in the audience. Thankfully he identifed himself after the talk and told me how they deploy regularly with the record from issue being opened to fix in production being “2 minutes”* (Actual time may vary – but rest assured it was not 6 months)
I have since heard similar stories at Amazon, Facebook, Netflix. Why does the enterprise (read ABAP based platforms ) have to be different?
The toolsets are available
Chris Paine nailed it early on:
The combo of abap unit test, a branch based repo and then bringing in tools to manage automatic migration and testing could have the possibility to pull ABAP based development into the 21st century. But why hammer the round peg into square hole?
— Chris Paine (@wombling) June 28, 2018
And there you have it:
- Unit Testing
- Decentralised Branch Based Repository
- Automatic Migration
- Branch based deployment
People like @grmpyprogrammer, Chris Hartjes, have been preaching Unit Testing to the PHP Community for years, probably 18 years. The toolsets and workflow are well established and while it has taken people like Chris years and years of banging the drum the message has gotten through.
ABAP Unit has been with us for at least a decade but how many of us unit test our ABAP code? How many of the ‘offshore’ code factories include ABAP Unit tests as part of their deliverable?
Where is the ABAP Unit culture? Happily there are more voices promoting unit testing recently.
Even in the Java world JUnit and friends have made testing common. Which is why Chris Paine is happy developing extensions in the cloudy world:
Rather than rebuilding the wheel to fit the juggernaut, keep the juggernaut running as standard as possible and apply enhancements outside of it. This is #SaaS enhanced with #PaaS
— Chris Paine (@wombling) June 28, 2018
But to do this he is using unit testing, branched based source control and automatic deployment mechanism. ( Chris may want to chime in and correct me here I dont actually know his workflow I am assuming it based on his tweets. )
Ethan Jewett had some really great comments to add – he joined in with:
No, really not. It’s a PITA, but every other platform in the world handles platform version changes and branches at the same time. Once you have code decoupled from the runtime, then developing and testing on a new patch level is easy peasy.
— Ethan Jewett (@esjewett) July 2, 2018
And unsurprisingly (as Ethan always has great things to say) there is another thread on modern ABAP practices starting here (from 2016) :
Great article by @esjewett
Implementing modern practices in an ABAP development shop https://t.co/1pAkgvc9vb
cc @ABAPCodeRetreat @majcon— Christian Drumm ?? (@ceedee666) December 30, 2016
and again as Matt Harding pointed out that this conversation has been going on for quite some time pointing back to a tweet from Chris Kernaghan from 2014.
.@njames Being going on for longer than a few days! https://t.co/7YrlRRLV24
— Matt Harding (@mattharding) July 2, 2018
And the kicker which really sums up the ABAP Culture is this:
I have to agree with @BoobBoo. The level to which many ABAPers are convinced that what they are doing is a special snowflake is astounding. Way beyond what I see on other platforms. I think SAP has to take some of the credit for that culture.
— Ethan Jewett (@esjewett) June 29, 2018
Personally – I have never wanted to stay with my own set of tools. I am not an ABAPer. I solve problems that can (sometimes) be solved with a computer program and I am happy to say that over the years I have contributed to many sucessful implementations just as I have contributed to things that have never seen the light of production.
About four years ago I took on a client who was the farthest from SAP as anyone could imagine. They were a content platform startup. Small team using PHP and a little framework called Laravel. Thankfully they didn’t let me at the code. I did a more robust data replication proof of concept for them. While I was there I learned a lot about how this team used:
- Unit Testing
- Decentralised Branch Based Repository
- Automatic Migration
- Branch based deployment
Sound familiar? Every other team and platform does this. Ethan is right. ABAP is a Special Snowflake.
So here is the cultural challenge to all those who are die hard ABAPers. You need to embrace the new tools and new ways of doing things.
I hope this has raised a thought and sparked more conversation.
Let’s not be doing something because it is Not Invented Here.
I will leave you with the Knights who say NIH
[and yes I wrote this blog in markdown using Sublime Text 3 and used github to version control it ]
Update – 4 July: Dennis has added his thoughts to this conversation and the comments are worth a read.
Update – 6 July: This post caught Hasso’s attention and is asking for feedback about what is really needed:
imo scp offers all or most modern code management and deployment options of the cloud world. many of the abap improvements will show up first in the cloud, only there sap can make more radical and incompatible changes because of the separation of standard code and extensions.
– hasso
Bravo! Nice summary, and yes your intuition was right as to my Dev/support flow... Although as you point out, it's not that hard to guess, as that is what pretty much _everyone_ outside of ABAP Dev does... ?
I'll add my additional slant on the conversation, which is that customers would possibly get a much higher ROI ditching the ABAP teams when it comes to enhancements and then using existing CI/CD tooling and SAPCP and people who understand it to support their enhancements.
But that lead on to the culture and dev/ops discussions...
And then we will just end up shouting Nih at each other ?
Bring me a Shrubbery
Hi Nigel,
although i didn't participate in the topic at hand and can certainly appreciate the industrial strength of ABAP, i liked most your including of tweets, linking, and tagging other fellow SAP cummunitars on the subject.
thx, greg
Hi Greg,
Thanks for your comments.
There is no doubt that ABAP is an industrially hardened language that is keeping the systems going in companies with billions of dollars of revenues.
We can continue to improve our practices and learn from other platforms.
"The times they are a changing" 😉
Cheers,
Nigel
Besides the political and logistical challenges noted above, I think there's another important factor in all this that had nothing to do with ABAP as a language, the ABAP Repository or TMS. For example, if we spin out the Python or PHP comparisons above, one of the more notable differences is that those programming environments don't come with the baggage that is the AS ABAP application server. To me, it's a LOT easier all the way around to approach CI/CD if you have a flexible, microservice-based architecture to work with.
Just the other day, I had a two hour call discussing the logistical challenges of rolling out a couple of simple OData services on an embedded Gateway instance. Here, I had to state my case to system owners concerned that this could interfere with month--end financial close activities, etc. Even though these services were innocuous and 100% unrelated, you can understand the trepidation because we've all had experiences where the smallest of changes break production.
Now, compare that experience with say Python. Here, I can create my services individually, package then up in Docker containers, and deploy them in isolation. And, if my services need more oomph, I can scale them horizontally without having to go stand up another app server instance.
To me, there's really no debate here as to which approach makes the most sense. What's interesting to note here though is that there's nothing really that special about Python or Node that sets them apart from ABAP. It may be a little verbose, but we could definitely accomplish similar things in ABAP if we had access to a more lightweight runtime environment. Maybe we're headed that way with the ABAP environment on SAP CP, but the question there I think is whether or not ABAP is better/more productive than other modern environments.
Anyway, that's my two cents: until you break up that huge monolith that is the AS ABAP, I'm skeptical about how much traction we can really hope to expect on the agility front with ABAP.
You nail it down to the point. It is not the language, it is the integrated platform that is a too large impediment for really effective usage of TDD, CI/CD, and non-linear development processes. Whoever read the famous books Clean Code and The Clean Coder knows that TDD plays out its strength together with iterative development and refactoring. Who wants to learn the “language” TDD should visit the “native speakers” in (mostly) Java and not expect to really learn in the “basic school” ABAP platform. Refactoring is just not supported on the ABAP platform so one of the most important tools is not available.
“The toolset is available” – if we look at the support on other platforms we get a realistic impression about the level reached. This level is low.
The ABAP platform (not the language) is more than a decade behind. Because there is no real market driving such an enormous transformation to get the code out of the platform and to break up the monolith and because few young developers will invest their best years into this platform, it will not catch up to other platforms, but the distance is increasing - e.g. look at Docker etc. - and will keep increasing in the future.
The ABAP platform and runtime is designed for small extensions, it is not competitive and future proof for large development projects in the long run
" the code we write in ABAP today is not the code we wrote 20 years ago."
Unfortunately, for many it is. Standard tables are used in favour of hashed or sorted. My anti-favourite FOR ALL ENTRIES is used in favour of joins. And if people won't spend time to get to grips with OO, then unit tests are a distant dream.
But! The code I write in ABAP today is radically different from what I wrote 20 years ago. And, since I did the ABAP Unit Test course on OpenSAP earlier this year, quite different from what I wrote last year!
Which is exactly why Robbo and I write posts like this and his "Call to arms" from 6 years ago.
And yes ... I am glad that the ABAP Unit Test course is on openSAP.
Thanks for your comments Matthew,
Nigel
The code I write today is so different from what I wrote 20 years ago. So very true. It is amazing. There are so many more tools. Switch from ABAP logical databases, ABAP lists to ABAP ALV to ABAP objects to ABAP CDS. Some where in there is WebDynpro, Workflow, and Sequel reporting tools. The reporting tools can be used by the end user. But to support them I learned that as well. Look at just the syntax. It is different. It is still a growing and changing language unlike COBOL Or Fortran.
Now let me add my next paragraph. There is nothing wrong with having many different options. There are times when I will use a different language.
So yes, I still believe ABAP is worth learning. AND yes, go see ABAPGit. Oh boy are you missing out if you don't use this.
Yes I am with you James – at one level they are just server side languages. ABAP has comes with a whole DB slapped on the back and for historical reasons that Vijay mentioned https://twitter.com/vijayasankarv/status/1013636904607076352 it is a whole box and dice that does a great job and is stable as .
JavaScript could get its own special snowflake award for changing frameworks every 3 seconds.
CI and CD are areas for improvement in the ABAP stack and awareness of ABAPGit and ABAP Unit and developers using these tools will force change on the C-suite.
(At least that is my hope – I am really looking forward to learning more about ABAP on SCP.)
N
Very interesting conversation, thanks for summarising it so far and extending it, Nigel!
A minor point, but I wanted to add some comment to the historical angle, only to provide background to where things are (and where things came from). My memory is rusty in parts, so I'll do my best.
ABAP didn't come from R/3, it came from R/2. Saying that it came "with a whole DB slapped on the back" doesn't feel quite right to me. It was added as a simple reporting language that was originally interpreted outside of the main stack (in batch jobs!), but as it evolved, modulpools (codebases behind transactions) and other functional and structural units that had existed in assember were rewritten in ABAP. For a time in R/2 there was a hybrid world of assembler and ABAP (I remember writing exits linking ABAP and transactional assembler code).
When R/3 came along the transition away from assembler was complete, and the core existed in ABAP, where the ABAP engine was a fundamental part of the entire R/3 architecture, including the major parts of the R/3 work processes: the task handler (which was the entry- and coordination-point for the dispatcher), the dynpro processor (that handled the PBO/PAI logic) and then, at the bottom of the stack, the ABAP engine. This in turn was closely linked with the data dictionary which provided not only an abstraction layer to all the different RDBMS systems that R/3 supported (remember Informix, SQL Server?) but also facilities that today we find directly in programming languages themselves, i.e. structure definitions and so on.
There's obviously a lot more to it than that, but I wanted to at least set the scene for ABAP's origins, a scene that at least qualifies to some extent where we are today. None of this background means that it's impossible to get to where we want to be, but I thought it worth sharing anyway.
Certainly DJ and thanks for jumping in here.
I think what I was leaning toward is that the code is compiled into the DB (if I am not mistaken) so the code artifacts are not file system objects in the way that they are in say Java.
For where it came from and the historical context ABAP certainly was groundbreaking.
Let’s not rest on our laurels.
N
Definitely, let no laurels be harmed in this process.
I'm assuming you meant James Wood . Please know that he won't be notified of this comment. We have to click the Reply button on the specific comment or use a mention, like I did here. Unfortunately, it's rather difficult to have a discussion in the comments on this platform as we're only notified of direct replies. 🙁
Yes I did. Thank you Jelena Perfiljeva . I only noticed that I hadn't replied to him later.
N
Hi Nigel,
exactly my thoughts (and yes, I've read the thread on Twitter, too of course).
A note to Den (I doubt he's reading this): contributing <> commiting. I know many Mentors and non-Mentors who contribute to abapGit (incl. me) by talking to the devs (in person, vial mail or even twitter or by raising an issue) without commiting one line of code.
To change the situation in the direction for CI/CD you (we) have to change a) the mindset of the ABAP devs and b) the technical environment.
a) is hard. As you may know I'm an employee since a year now (after 20 years of freelancing). Changing the mindset of "my" developers is very hard if not impossible. I think I've reached less than 50% during my trainings (OO, Clean Code. Eclipse, Unit tests,...). That can't be my fault only 😉
b) is even harder I think. As long as we only have ABAP development on a central development server it's quite impossible. I'm preaching since years that we need separated runtimes for every developer, let it be local or on the server itself. (this would also solve the problem, that ABAP in SCP needs a whole ABAP stack for every customer)
Hoping the best for the future.
And as always: #ABAPsNotDead
ABAP is most certainly not dead. It not deadness is one of it's most enduring attributes.
As you say the central development model of ABAP is one the key things that makes it tricky for CI/CD.
Thanks for your comments.
Cheers,
Nigel
For CI look at how Salesforce is doing it with DX. You have a “scratch org” model where the CI process can spin up an environment from zero (cloud) , run the unit tests and then delete the instance.
This is critical for CI the hability to generate clean environments on demand. SAP is the opposite of this.
There is a though I just recently had:
It would be nice if I could have a clean, “use once, then throw-away” SAP instance (probably from the Cloud).
I'd say I need like SAP_BASIS 7.50 + SAP_APPL 618.
order. (probabaly wait a littel time 'til it's there).
I'd the install my AddOn to it, and let a few eCatts run.
-> Get/Save the protocolls and throw away the system.
(Next day/week/?, when I improved my AddOn , I'll do it again).
I can imagine this is technically possible (why shouldn't it be?), but I'm not sure if someone is actually offering such a thing.
A competitor in the cloud space that SAP declared recently as a "nemesis" is doing it. Can't SAP do it too? 😉
Surely they can 🙂
Here we go again...
But why do we need to embrace anything? Just because "other languages are doing it"? Um... If other languages jumped off the bridge then should we too? 🙂
With backwards compatibility, SAP makes it too easy to program like it's 1999. Today, I can write a horrible program using FAE, binary search, tables with header lines, use obsolete FMs - ain't nothing stopping me, unless you put some mandatory checks in the transport release. (Which many companies don't do.)
As long as the program runs and doesn't cause huge performance problem (and if it does we'll just hide it in a background job), the business users won't care either. And business is paying ABAPers salaries.
The older ABAPer generation is moving to retirement. There is little incentive for them to care about what happens after they retire. Not saying that about everyone over certain age but let's just be realistic and honest here.
Slightly younger ABAPers are looking around nervously since, as you're saying, we should just all be fired and replaced with people who know better how to do stuff. And SAP is sending us mixed messages. One year ABAP is dead, everything is Cloud. Next year - hold on a sec, where are you going, we're not dead yet. But then, realistically, how many current SAP customers are going to drag current ABAP with them when they go to S/4HANA (assuming they even remain SAP customers)? It'd make more sense to go "greenfield" and just shed all custom ABAP.
So if ABAPers chose to make as much money right now using good old knowledge instead of investing in the skill that will become obsolete soon - that seems like a rather rational decision.
In Marxism theory, there is a term revolutionary situation. To start a revolution, you need that kind of situation: when "the bottoms don't want and the tops cannot live in the old way". I don't think we're at this point in the ABAP world. There are some sporadic upheaval here and there but overall, as I mentioned, it's entirely possible for "the bottoms" to carry on while "the tops" are content with that.
Not sure how long this will continue but I'm guessing until everyone abandons their ECC and most ABAPers will be sent to the farm upstate (much to Chris Paine 's chagrin 🙂 ). Natural selection will sort out the rest. I.e. evolution vs. revolution.
...aaaand to learn more ABAPosaurus Evolution make sure to book a TechEd LV ticket and attend my session (which I hope won't be scheduled for Friday). : )
Cheers!
(only a short reply from my side because I'm just waiting in my car on a parking lot waiting for my son)
You asked "why?"
Because your don't have the time anymore to understand unreadable code.
Let me quote Bjoern Goerke from the post you mentioned.
Other languages are not "jumping off a cliff". They are on the TGV fast track to innovation.
In many ways ABAP is tied to the train track.
The business users care when the FAE fails - loads a millions of records and then due to a logic fault ignores those millions of records and then keeps running but an order of magnitude slower. Perhaps an automated test could have found that error?
We all love ABAP. We all want it to continue to innovate. We all need to improve. #LifeLongLearning
Cheers,
Nigel
It is impossible not to like Jellana – but ….
I am not interested in working in a stagnant industry. One of the great things about this industry is that it is always changing. Not interested in working for Kodak, Blockbuster or a fax machine manufacturer either.
I am not interested in working with stagnant tools. I have my favourite text editor – but it regularly changes as better ones come along. Abobe Flex was awesome in it’s time – not so now.
But I do want to be better at what I do – and doing the same thing over and over again wont make me better.
I want to improve my tools, techniques, knowledge, experience, etc.
I want ABAP to be better too. I want it to continually improve. And it has been improving quite a lot – apart from a few years in the early 2000’s when SAP was distracted by shiny moving things.
And if my tools improve I want to learn how to use the improved tool in the best way possible. Why would you try and chop down a tree the same way you did it with an axe when you have a chainsaw?
Maybe it is just me? Perhaps it is all about my short attention span?
For those that have taken the decision to just coast through – whether to retirement or otherwise – I can’t criticise that as long as the reasons make sense to you. After all “enhancement framework wont give you a hug” and no one on their deathbed ever said they wished they spent more time at work.
For me – I believe in lifelong learning. So I am afraid coasting through wont work for me.
On my deathbed I am 100% certain I won’t be saying “ABAP” – but I might be saying “learn”.
hear hear!
I’m a strange “ABAPer” in the sense that I also work with node, angular, Apex (Salesforce) and .Net. With all those tools Git is a critical part of my workflow. I would be the most direct use case for AbapGit when in the SAP world.
So do I use it when working with ABAP? Not really, so I started wondering why , why don’t I feel the need to use a tool I already use in other contexts?
1) Culture for sure. I can’t be the only one to use abapgit (and unit testing, OOP) so I have to convince everyone else... huge challenge.
2) STMS is actually great. I’ve had to setup huge CI/CD landscapes from scratch, and a lot of time is spent maintaining them . This comes for free. Unless you want to run unit tests ... why bother with anything other then STMS? (And unit testing could be added to stms)
3) You need an environment to run the CI pipeline. The way SAP is built this is not easy/reliable.
4) Unit tests are not reliable enough to do CD on a business critical system like SAP. Is anyone actually doing CD in S4HANA?
SAP gives you for free some of the tools other frameworks don’t. With .Net I need a version control system which SAP provides out of the box, the same for deployment. As someone who shifted from a pure SAP world to a more broad landscape, I have to say SAP has spoilt us with the ABAP AS.
Wow Nigel James , so here it starts! Let me put my 2 cents here from my experience, Most of the ABAPers I feel 99%, suffer from is a very common disease which i call as "#ABAPInertia". I myself was suffering badly from it 3 years back, infact SAP in itself was suffering from it i feel.
Everything was built around ABAP whether webdynpro, module pool, webui etc. which sadly did not work. The real game changer was actually when #SAP themselves adapted to WWW world of Javascript via UI5. This is where we started embracing the #OpenSource the world outside SAP.
Today we have reached a stage where #ABAP is fighting for its existence( It is the closest to my heart), the only way to survive in the world of cloud/mobile/AI/Blockchain etc is to innovate and move forward.
I will be the happiest person if we can use ABAP to create a Blockchain, AI, mobile apps etc. etc. But if it does not then we will have to embrace the new technology no other way around. I believe "#ABAP is like a slow moving elephant with each step forward it leaves a deep imprint behind".
Good thing is ABAP is moving forward slowly and steadily, I hope someday we will be using #ABAPForEverything.
Thanks
Nabheet
Thanks for your thoughts Nabheet and as much as I love ABAP it is just a tool.
The point I was trying to make in the blogs when said I am not an abaper is that I will look to the right tool for the job. Sometimes that is ABAP - particularly if the context is ABAP, most of the time it is PHP is the context is web and if there is a sniff of data science I will be reaching for python. If there is a joke to be had I reach for Monty Python (Is this the 5 minute argument of the full half hour?)
One of my larger points here is that SAP not play NIH with #ABAPgit and actually make good on their promise of integrating it into the ABAP stack. They are often shouting about how much they love and contribute to opensource so this is one great opportunity they can actually do so.
Cheers,
N
I will agree here, the contribution towards open source is something SAP shall work on rather than shouting loudly. Let the contribution shall speak louder than the words. the direction in which SAP is planning to go #ABAPGit is a must.
Thanks
Nabheet
I have nothing against learning in general. Quite the opposite. Even though I still use SAP GUI and don't clamor for ABAP Eclipse at all (although I switched to new editor last year - that counts as an achievement 🙂 ), I always want to do my best. Just like you, Nigel, and many other people commenting here and contributing on SCN. But, as Matthew Billingham correctly pointed out, we seem to be in minority. Essentially, Nigel seem to be preaching to the choir here.
Reaching the other part of population - that's where the challenge is. How do we best reach them? So far simply waving the "you should learn" flag from the barricades doesn't seem to be effective, from what I see.
Programming is commonly treated as a commodity service- all programmers and all programming are/is of equal value.
Until the powers that be recognise that an intelligent, trained group of developers will produce considerably better programs that are cheaper (in terms of Total Cost of Ownership), I see little chance of change.
The outsourcing companies and there consultancy partners are making far too much money to want that kind of change and will actively fight against it.
It's clear, however, given the way ABAP is going, that SAP at least do not have this mindset, so maybe there's some hope. And in one of my clients, after discussion with the quality group, we now have a set of development standards that state that TDD and ABAP Unit Tests are best practice. (I also managed to get the old-style non-DSAG recommended prefixes removed!).
As someone who works for a major consultancy at the management level, I can say I disagree with that we are fighting against it.
It is true that customers are not willing to pay for quality work, and that’s the main issue. Customers need to be demanding, they need to either pay more for quality work, or stop hiring cheap workers who do lousy work.
When you have the customer fighting to save every single hour of development, you just can’t afford to do things the right way. I recently had a customer questioning 80 hours of development, when you had to use these 80 hours to:
6 hours alone were spent in workshops, because people talk about everything except the topic at hand for most of the time.
This is the problem. Not wanting to pay the time it takes to properly develop, even though the extra time will save tons of money in the long run.
It’s against our best interest to write troublesome code. Best case it harms our corporate image, but mostly likely will hurt us financially too. The race to the bottom doesn't help anyone except the guy at procurement.
Oh - I agree so much with this response. It's sad but normal. Workshop's to get the requirements. I do get a GENERAL idea from them.
Then I am expected to make up the rest. HA! That's doesn't happen. So it takes more time bothering them at different points to get the answer.
Oops - I just gave a reason for unit tests.
Michelle
Jelena,
While I definitely agree with your comment about not just blindly following the latest trends, I do think that this particular trend is much different than some of the ones we've seen in the past. In my opinion, the evolution we're seeing now has very little to do with whether or not one language is better than another. I am actually a big fan of ABAP, just as I'm a fan of Java and C#. In many ways, I think that all three of these environments are at a crossroads due to the large amount of baggage they carry from the 90s and early 2000s. Realistically, I just don't think there's much of a place for app servers and complex, monolithic landscapes in the cloud-based world we live in today.
Also, I do think there are lessons to be learned from watching what's going on with Java/Spring and .NET Core. These programming environments are evolving to become much more lightweight and flexible. And yet, the sourcecode looks largely the same. ABAP can achieve similar things, but both SAP and the community supporting it must embrace change to do so.
And that is the problem. How do you get them to support it? My challenge to everyone and Jelena's challenge was to give an example in a blog.
Could you do that? I've seen some really good ones and would love to see more. I'm sure there are more. I just am struggling to keep up with the community lately.
Michelle
ABAP Unit tests - Freedom!
ABAP Unit Tests a real world example for Jelena and Michelle and everyone - really
“Greenfield” sheds old ABAP code. Mmmmm... There was a reason that code was written in the first place. Is the reason gone or still there? 😉
Yes, dragging some of the code is worth it.
Auto-code checkers are the bane of my existence. Sometimes that don't quite work with performance. So you will be adding things like
I think I've used needed the most. The no_transformation one the second most. Anyway be aware when you are moving "old" code to a new environment - some of it isn't pretty. You may not have the time to try to understand what on Earth was written. Sigh. So you bring bad code to the new environment.
Also some of the times the checker is wrong. Sometimes it is correct.
"Is the reason gone" - that opens the whole other can of worms. 🙂 E.g. we have the whole "suite" of Z programs that were written back in the late 90s I'm guessing. They may have been great at that time but since then SAP added some new functionality. E.g. most, if not all, of what that code does can probably be replaced by a proper WM implementation. But, of course, that would be another project, so instead we are just dragging around the existing Z code. (Which, at this point, looks like a zombie that's been shot multiple times but is still dragging their feet.)
As a side note, I believe rarely customers have a systematic review process of the enhancements delivered by SAP. For example, we implemented a user exit in VA01 for some additional validation. 2 years ago SAP actually delivered an enhancement in the note that allows to do it without even any ABAP. I no longer work at that company but I bet the user exit is still there. Because not only you need to know about the replacement. You also need a ticket, a business person to test and sign off on that, etc, etc.
This is code we originally were not taking to the new system. We were going to start vanilla. How's that work for anyone?
OK so that said did we originally take any custom code over? Only a handful made the cut.
Now the realization - Yes, our business is different than most companies because...
Next:
Do we want to pay for that option? Does it still belong in our system? Look at the "new" integration test. See if it fits anywhere? If we need it, and there isn't a solution in standard SAP <Gasp>, then we bring it along. If we don't it goes into save mode in case we did need it and didn't know we needed it. You know the old "If you don't know what to ask for - you may not know what is needed.
So - to your point many programs went into the graveyard. But we still needed other ones, because there is something special about our company. Also we are taking a big leap into S/4 HANA.
Take a second and think. I bet you can think of a program that is needed, and is not covered by standard SAP.
Dragging bad programs around - HA! - leave those in the save in case we have to have them pile.
During an upgrade, it's a great time to take inventory.
All that is true. But then there are also tools like custom code management, where one can actually see an inventory of the custom objects you have.. and use. And during a dbase migration to SAP HANA, all the legacy code needs to be reviewed and modified. An excellent time to clean house (and dump the code you wish to keep in case of in a separate package > nugget (or abapGit).
Also, if you consider the cloud solutions, then I presume that in the future, business processes will aligned with SAP, and not the other way around.
All of it was looked at and considered.
Did we look at the on-cloud version? Yes.
"Also, if you consider the cloud solutions, then I presume that in the future, business processes will aligned with SAP, and not the other way around."
And that was one of the many reason on-premise looked so inviting. SAP does not and can never duplicate all business processes. All the little ways that makes your business run smoother and more efficient. Why? Because every business is different. In general you can say, yes it meets our needs 80/20 with configuration. But it is that 20% that helps save processing time. That means money, it could mean a lot of money.
So you say - no big deal have SAP program it. For how much money? A lot more expensive than the 3 programmers we have. (Smallish company)
On no - I didn't want to debate on-premise and in the cloud. They both have great benefits and you really should look at both.
So yes, we drug (dragged) the code with us that made sense. Oh by the way - each module you add is more money. And perhaps you only use 5% of it. Custom code was the way to go.
Michelle
I agree(d) completely Michelle Crapo.
But then there is the SAP SuccessFactors story, where I see more than a few of our customers move towards cloud-based solutions. And if it can work in that domain,.. etc.
Smile. There are pros and cons on both sides. No one straight path to take. 😉
I just makes me wonder about the future of the "ABAP Developer". Or let me rephrase that: it makes me wonder what the required/preferred/ideal skill set of that developer would be.
Very true. It's always a good idea to update your skills. And if everyone is flocking to the cloud. (really?) then you would have to update them or work for SAP. However, I'm going back to last Teched - they say ABAP is still a usable language on the cloud.
Companies have invested heavily just to get us all up to speed on ABAP. It's not something they want to completely lose.
When I get some time, I have the advantage of sitting with some consultants to learn new things. OK and I'm jumping head first into others. Someday I'll write a blog. Someday...
Great conversation in this one!
Hey Nigel,
I totally agree with you. We must start moving towards innovation and find smarter ways of doing things rather than JUST doing things !
Cheers,
Pradeep G.
True. But learn from what someone else has "just" done. Be smart about applying new languages. Understand the if it is supportable.
I was at the abapGit meeting in Southern Germany last Saturday. It is literally amazing how good abapGit is already and it gets better with every single passing day.
This is also a snowball. The more people who use it, the more problems they will find and then - hopefully - the more they will start contributing.
How I explained it to my wife was that there are two sorts of custom development - specialised for your industry - concrete, automotive, chemicals or what have you - which give you a competitive advantage, and boilerplate code like logging and the like used by every single company.
So if there are 200,000 companies with SAP development departments, that means that 200,000 different custom Z logging frameworks have been developed, all wrapping the standard BAL function modules in some way. In fact there may be more, with different developers in the same company creating their own Z logging frameworks.
The answer is to have the boiler plate things be open source projects, managed by abapGit. You also would not belive how many side projects Lars (inventor of abapGit) has going, all of them revoluntary in their own way.
I am also doing TDD in my day job for the first time and you would not belive how well that is working. It is forcing me to design my program properly.
Here is an example of the maxim “as the tests get more specific, the code gets more generic”.
In this case I had a business requirement that after the user enters the customer the ship-to list must automatically appear – but only once. If they exit out of the list then they must press F4 to get the list again. Otherwise you get an endless loop.
So I handled it by a “global” (member) variable to say if the list had already been called.
Now I have another requirement that after the customer and ship-to have been entered, a box appears with the customer header text (if it exists). If that box appears it is also a once-off event.
I have written my test as to whether the text box appears, of course that test fails at the moment.
Now I need to fix my problem. I could have another member variable saying whether the text box had been called, but down that path lies one hundred member variable flags.
Instead I need to enhance my popup handler class so it keeps track of what pop-up screens (each screen is a process in this example) it has displayed thus far in a good old internal table. Thus the popup class is keeping track of what it has done rather than the main application which is a better distribution of responsibilities.
The calling code is changed to:-
And in the popup handler the one-off check is made.
I can now add my new check to see if the customer text pop up is required.
I will end up renaming everything ten times, but the principle is clear. Instead of relying on an ever increasing number of flag variables, I now have a generic way of handling as many one-time pop-ups as are required. Moreover I have been forced into following the single responsibility principle, whether I like it or not (which I do).
This is proving the point that the more tests you write the better the code becomes.
Yesterday the colleague opposite me said he got bored and so wrote a few unit tests on code he had written that day. He quickly discovered that about four assumptions he had made were wrong. So in some ways the automated regression testing, though wonderful, is not the main benefit - the main benefit is better written code.
In summary if whacky radical things like "test driven development" and "github" are bridges that programmers in other languages have been jumping off like lemmings for ages then I am with James Borown on this one i.e. I want to shout "Take me to the Bridge!|"
Cheersy Cheers
Paul
I would wager most companies won’t allow their employees to sharing their IP as open source.
Maybe some newer players , but large enterprise are usually very strict about it. For professional development I always use private repositories because of that .
I do use Github but if you look at my profile (jgsousa) it’s all hobby development all the pro stuff is hidden because it must be.
As I said there are two sorts of development.
One is the sort I do in my day to day job. That is the intellectual property of which you speak, the programs that make my company different from the competitors. There is no way you would open source that sort of thing on the internet, as you would lose your competitive advantage.
The other sort of development I do at work is the boilerplate sort of thing which is a waste of time when I could be doing something that actually adds value to the company. Why should I write a framework to dowload data to Excel in a lovely way when I can just install ABAP2XLSX instead?
This is of generic tool development is typically done by people outside of work hours, and is the sort of open source project abapGit was designed for. That way instead of 10,000 people all working independantly on the same thing, you have several dozen people all working on the one thing (and 9,900 people hitching a ride) and a better quality boilerplate solution.
I don't think the management at most companies actually care what sort of version control or unit testing or logging tool you use as that is internal to the development department and not perceived as any sort of benefit to the business....
Even if it’s outside of work hours, it’s can be tricky if you work in a large enterprise. Did you use your company laptop? Is it related to work you do during the day?
I’m being the devils advocate here (the annoying one) but sharing abap code may not be that straight forward.
But yes, the company doesn’t care what tools you use. It may care if their IP is publicly shared (even if it is a logging framework).
Have your laptop beside you - log in via an open network. Then you are ready to rock. Even using your cell might be helpful if you are stuck on something.
The code you wrote for your company. I guess I could argue I would get a huge benefit from using it and downloading more code than I added. (Of course, I haven't added anything YET)
My company has wormholes where we can look at outside info and download. Plus I work at a small company.
Just came here to say this - yes, the concerns about the employer's take on your extracurricular activities is the major reason why I refrain from sharing any code. Even if I use a personal laptop (obviously), there are still some grey areas. "Better safe than sorry". I'm glad others are sharing for my consumption though. 🙂
Thanks for this contribution Paul and I was really glad to be able to link to your other material here on SAP Community. Keep it up it is awesome.
There is a bit mental shift to writing tests and that is the journey that ABAPers must go on. It is not enough to say if it runs a bit long you put it in a batch job. How do you know that it won't fail and take out your servers?
"Keep us all honest." He says as he smiles and passes you a Vegemite sandwich.
Cheers,
Nigel
The mental shift is small compared to the learning time needed. I believe we all want to do better. The change management with our company could be large. Meaning I may want to learn it but there are only 2 other programmers. I have to convince them to learn it to. Otherwise there will not be any backup. And sorry - yes at times it is that big of a change.
So I may be a cheerleader and want to change. They have to want to change, AND we all have to have the time to change. Doing it gradually is nice. Keeping the pace to all of us even better. However, now we have consultants that are great and are completely using the new tools. Or the flip side consultants that are using the old tools.... That gets to be a juggling act as well. 🙂
Github is amazing. I seem to remember something here about ABAP code/snippets. GitHub is so much better. Changing the code and starting projects is fun. (I've just used it so far, no adds from me yet.)
Test driven development - no I haven't done that - that's a big mindset change for me. However, I have added test to my code. (Just started doing that) 🙂 This is hard when not using the test driven development as it adds more time to put it there. Why do it? Yes, I've caught errors before production.
I think tests brings with it several advantages:
I started using tests a lot with another software as it forces you to have 75% code coverage, and I have to say I have basically cut down my debugging time to zero. I just run the test, look at the error, and if the test is well created, it shows what happened. In the end, it saves time.
Much more effective and scalable, then optional debugging. On big advantage of the other software over SAP, is that all data created during tests is deleted after the test runs, so you can easily test inserts, updates, etc (database layer). In SAP, testing the DB layer is a bit trickier.
Hint: I see another volunteer. Do you have a nice business example? Did tests help you out? (Yes) A blog... Yes, another blog in the making.
I love reading the blogs out there with simple examples. They help a lot.
+1 to Michelle - if you have a success story / specific example to share please do so. The examples used in openSAP course were not very helpful IMHO. But so far it seems Paul Hardy is the only one on SCN who've actually shared his practical experience. Others are just claiming this is the best thing since sliced bread and I remain skeptical. But then I don't think sliced bread is that great either. 🙂
So the experiences of other languages and platforms is not enough?
I have worked on codebases that have test coverage and those that have 0 . Guess which one I am happier to make a change to.
I totally get that it is a journey and it is a mindshift but as Joao Sousa says - there are benefits.
But "Why should I change?"
No idea Jelana - that is a question for you alone to answer. After all the tools have only been around for 12 years in ABAP ( probably longer ).
Happy days,
Nigel
The experience of other languages is not enough because the context is very different.
- Most are not server based like ABAP. They don’t have build/deployment infrastructure or a version control system “by default”.
- Unit tests are mostly suited for stateless tests. ABAP program are highly reliant on state/DB which is almost impossible to test .
- Core SAP has no separation of concerns. Most of your code interacts with standard SAP, mocking those APIs is close to impossible.
- Doesn’t have Dependency Injection which is testing 101.
Does it have it have advantages? Yes. Are they the same as other languages? I don’t think so. That’s why my success story is not with SAP.
The reason I can’t really share is because the experience is mostly with another software stack not SAP, one that forces me to write unit tests, either I like it or not.
As I’m being forced the rest is a result of that, I have to write modular code because I’m forced to do it. After I while I just started doing it because I realized I actually used the tests a lot instead of debugging, and it was simpler/faster.
I don’t think it’s something you can explain, you do have to experience it.
That said I don’t think it’s the best thing since sliced bread. From my experience there are a lot of types of bugs it doesn’t catch (it’s unit tests after all) so I don’t trust them to do CD.
And we are mixing a lot of stuff in one post:
- Git : no brainer for code sharing, but with caveats for IP restrictions.
- Unit Tests : not the best thing since sliced bread, but some will find useful.
- CI : running unit tests automatically after every change. I find this very hard to do in SAP without something like scratch instances.
- CD : deploying code to production after every code commit and CI run. This I would like to know ONE real story. Just one. I don’t believe anyone is actually doing this (sorry, skeptical one here )
When people talk about CD they are mostly talking about automatic integration into a test server but in ABAP AS this is automatic.
I have spent the last 2-3 years with half a foot outside SAP. If I thought these things were absolutely critical to my abap work I would use them, but I don’t .
Completely agree with you. ABAP is simply not like other languages. It does some things better, some things worse. Just like any other language. So yes, ABAP is a snowflake but not in the negative meaning which this word seems to have acquired lately, e.g. when referring to the annoying entitled Millennials on Twitter.
Hi Jelena,
starting with Unit Tests isn't that hard if you implement new functions.
Here's how I'm doing it (your real world example, but not TDD). I'm using constructor injection, because this possible in all releases:
Create three classes
That's it, no magic.
If you have to extend existing code, I'm always telling the devs to create an "Island of happines" -> do all the new functions in your own class, test them and call this functions from the existing code.
(but I think we are in the wrong thread here to discuss this)
So I get to say it again...
I see a very nice blog that you could write up. It helps the doubters like Jelena and myself. Plus it adds a nice story. This is the old code. This is the change to that code. This is the "island of happiness" after/during the change.
Stay tuned, give me an hour or so....
Here you are: ABAP Unit Tests: real world example for Jelena and Michelle
And here you go, my success story. ?
Michelle and Jellana
Thank you! Loved the blog.
If you want to read a lot of words about how I wrote 1 (or two) unit tests (covering real code!) you can do that now; https://blogs.sap.com/2018/07/25/my-experience-with-real-world-unit-testing-abap-unit/
I think we may need to start a Wiki page or something to keep track of all this stuff. 🙂
Wait, there's a Tag for that! 🙂
But I agree: if everyone uses her own choice, it doesn’t help so much!
(Maybe that Wiki page could list the user-tags? 😉 )
I went for using user-tag https://blogs.sap.com/tag/unit-testing/ (within primary tag ABAP Development, so it should (some day) be possible to filter out Non-ABAP-Unit-Test-Blogs! )
Thanks for your comments Michelle.
Come on in the water is fine.
N
When I do - it will be jumping head first. So I'm very happy to have some nice water.
"So if there are 200,000 companies with SAP development departments, that means that 200,000 different custom Z logging frameworks have been developed, all wrapping the standard BAL function modules in some way. In fact there may be more, with different developers in the same company creating their own Z logging frameworks."
Spot on!
Having got stuck into Node more recently (and loving it) I'd love to see NPM for ABAP (APM).
For me the best thing about the ABAP platform is the transport system. Do not forget about it in any conversation or plans 😉
Hey Miguel
Thanks for chipping in. Perhaps you can detail the strengths in a blog of your own.
For me I am regularly frustrated by locks on an object which are not released until a transport reaches production.
But perhaps I am just "holding it wrong" I would love nothing more that someone to show me how I can have multiple streams of development and production hot-fixes.
A branch based code repository makes this easy.
Cheers,
Nigel
AFAIK lock is released as soon as the transport is released. Why are you saying the objects are not released until a transport is in PRD? Is this some CHARM thing? Or a company policy?
It may be a charm thing - or may be policy.
In either case it is hard to do a hot fix on prod if you have already moved dev forward. This usually means a two stream landscape which is effectively "the branch". one of the other alternatives is winding dev back.
Maybe because of the culture and knowing how the tools work this may not happen often. Now working in a UI5 environment when you can branch to start the new feature without interrupting testing I struggle when my ABAP colleagues say they wont start a new feature because we need to ensure that the previous piece is promoted past UAT.
Hard is relative I'd say. There are different ways to deal with maintaining productive applications, at the same time as developing new features for the same applications. At the same time, it depends of course on what it is that has to be done.
But I can see the fun when you're working with several developers on a project and they all start branching out 🙂
Some examples I've encountered in the past:
But I guess in the end a lot depends on the willingness to find a way to do something. Often we're tempted to use the easy 'why not' excuses.
Thought this Reddit post is rather relevant here: JavaScript is getting real tired of your jokes 🙂
SO now I know my problem. I couldn't possibly find the right language as there wasn't one.
One of the most interesting conversations I've read on the SAP Community so far. Congratulations to all of you who comment here and wherever else this conversation has been taking place on the last few days. I spent a fair time now reading and pondering how this reflects on our future as technologists in the SAP world.
After eight years working as an ABAP and Workflow developer, I began to explore SAP Screen Personas and a little bit later I did the same with SAPUI5. These two things opened my eyes on how to add new valuable tools to my skillset.
If you are an ABAP developer it is definitely not easy to learn SAP UI5 and everything that comes with it. I like to say that it is almost as hard as learning to speak German if you only speak Portuguese (or vice-versa). It certainly makes lots of people to avoid or stop the (huge) learning effort that is needed.
My opinion on the "cultural legacy" is that people are afraid of change because change usually means a lot of additional (and often unpaid) effort. Once you are OK with the idea that you are an expert on something (ABAP) and a complete novice in another thing (let's say UI5), it will not be hard to put the effort and, in a few weeks, you will have something new and extremely worthwhile.
For an ABAP developer trying to go out of the "special snowflake" mindset, I strongly suggest giving a try to SAP Screen Personas before going to SAPUI5. It is because it is a powerful tool to do an extreme make-over on the SAP UX while you can use both ABAP and JavaScript to achieve more powerful and complex things (making everything more simple for the end-users). SAP is clear that Screen Personas is evolving (it has a team on SAP Labs Palo Alto) and it is extremely valuable to both ECC and S/4HANA customers.
Sigh. Sometimes you have to jump head first into the water. Learning new things in advanced is very helpful. I had a free class in opensap.com. It was very good. It was on the S/4 Hana Migration toolset. It was very good. AND it helped a lot. If I hadn't taken it earlier I would have been lost.
So my advice, try some of the free courses when you can. Get the basics in case you need them. If you don't not a problem, you still learned something new.
Michelle
Nice read, thanks for starting this discussion (an special thanks for bringing it here to SAP Community!)
One thought on:
To my understanding, JUnit was what unit testing started with, so I can’t understand the astonishment I think i read out of this sentence ("Even in the Java Word") !?
best
Joachim
Haha - yes you are right. Most xUnits are based on Junit as it kicked this all off.
The (fake) incredulity comes from trying to point out that ABAP is not the center of the universe around which everything else rotates.
"What they do this in java too? Maybe I should add this to my ABAP"
Thanks for your comment.
cheers,
Nigel
Nigel James
This is a great blog! Thank you.
It reminded me of one of the (perhaps) ealiest documented and publicly available account of an agile ABAP development project back from 2007 based on NW 2004s: http://xunitpatterns.com/~gerard/agile2007-erp-paper.pdf
It is refreshing to read this first-hand account of struggles against the "ABAPer culture" that you blog and discussions capture well.
Perhaps there is something the community could learn from their experience and how they overcame (partially) some of the cultural and technical hurdles.
In the end they had this to say:
Very interesting discussion! I'm a little bit late to the party, but still want to add some information.
Since last year in July several SAP customers joined forces and are discussing DevOps methods / practices in ABAP landscapes in a dedicated DSAG (german speaking sap user group) working group. At the beginning it was mostly a self-help group to discuss the issues and pains, but also the success of the specific companies in several areas. Over time the group got bigger and now includes SAP employees and ababGit contributors as well.
We created an overview for the DSAG Tech Days in February 2018, which you can find here: https://t.co/sxfAKNnRRh.
At the moment we are discussing how to spread our insights in more detail. A SAP Community post will probably follow soon! 😉
The next meetups are planned for August (knowledge exchange with SAP IT) and September (ababGit), stay tuned.
Cheers,
Sascha
I'd be very interested in your work and can help with PR. Please get in touch with me - email is in the profile.
Thank you!