#30: ABAP Algos, Airtable, Refactoring
Hi there,
Happy New Year!
We are excited to welcome you into the new year, new you, and new Nerdletter distribution platform! In addition to receiving this newsletter by email (and, hopefully, forwarding to your friends and family or heck, even enemies, a subscriber is a subscriber, right?), you will now have an option to post the comments, discuss and share specific stories more easily.
What will remain the same is our commitment to you to share 6 stories that are never dull and provide either a refuge from or insight into the enterprise software world.
Cheers!
-Jelena and Paul
What are you doing with SAP?
There has been a recent influx of odd SAP Community blog posts in ABAP development space that made me wonder what are y’all even doing with your SAP systems? ABAPers don’t usually wake up one day and start implementing a PDF printing solution just for giggles. Someone is telling them to.
Historically, anything code-related in the SAP world has been considered the developers’ responsibility, for better or for worse. I suspect that led to many bad solutions and ABAP development used to solve what could have been achieved by using configuration or other means. Not to brag but in my very first SAP project I found a solution just like that and avoided implementing some nasty user exits.
It’s always been exhausting to figure out what’s going on in all the different modules (and it doesn’t help that almost all of them were built by different teams with their own vision and approach to programming). But these days, there is already a lot to learn for SAP developers just to keep up with technology. This puts the onus on the functional experts to follow the latest and greatest in their domain and to guide the developers accordingly.
That doesn’t seem to be happening though, judging by SAP Community posts. Is it the lack of awareness and education? The Law of the instrument? Is it just too tempting to push requirements to the developers because they have no one else to push it to?
Whatever the case, I think SAP customers need to figured this out. Otherwise it’s going to be super difficult to get to “clean core” and Cloud, and all the groovy stuff. JP
S/4HANA Packing List
Astrid Tschense serves up a series of blogs on "Technology Essentials for Moving to S/4HANA" (currently stands at 15 entries - I wonder how many will eventually exist). Here are a few I can vouch for - or complain about.
#3: Don't Just Rework Custom Code - This makes tons of sense. Blindly adapting ages-old code to make the jump, when often its purpose is long-forgotten, can be a huge waste of time. But speaking of time, I keep hearing that some companies making the S/4 jump don't plan for the proper time to rework and mitigate that code. If your system was stood up in the 90's, or has had multiple integrators at the helm over the years, it is a near certainty that there are nasty creatures waiting in dark corners to come out and cost you time.
#6: Gain Insight to Build a Solid Business Case - This sounds like a smart approach, and includes links to some free analysis tools and documents available for customers. I also, frankly speaking, haven't heard too many people who wait with excitement for features they're about to see in S/4. Motivations seem to be a little weighted to the other end of the scale: we don't want to be shut out of product lifecycle support.
#13: Accelerate Your Rollout with Test Automation - My feedback is starting to sound repetitive: this sounds great - but who out there actually does an amazing job with test automation? Is this a part of the landscape like system administration…the very best work in this area means you're hardly ever heard from except the occasional thing going wrong?
Reading through the whole list - kudos to Astrid for putting it together - gives me the understanding of why moving to the cloud continues to be an urgent initiative. Upgrading SAP has always been a nightmare - may the cloud save us all. PM
Airtable: Spreadsheet on Steroids
Let’s face it, people love spreadsheets. SAP has gone to great lengths to ensure that the world's economy is not run by a bunch of spreadsheets, but blink and business users are back to their shenanigans of tracking delivery times in Excel.
Creators of Airtable went in the opposite direction and decided to fully lean into the spreadsheet addiction. And I absolutely love the result!
Their marketing message “Connect everything. Achieve anything” is oof (and, oh yes, we made fun of it in our Nerdletter Talk video) but in a nutshell, it’s “a spreadsheet on steroids”. If you ever tried to insert a screenshot into Excel, you will be immediately sold on Airtable.
After signing up for a free account (no credit card required), in just 10 minutes I created an experimental bug tracking project with a dashboard that otherwise would take 3 different tools. I’ve not even gotten to the workflow and automation part yet could already see many potential uses for this app in my daily life.
And I’m usually not the one to use Help in such products but if you do, it’s also neat functionality that showcases well-structured content. Grab your Airtable today, before it gets “murdered by acquisition”! JP
Start the Year With an End of Year List
Peter Baumann does what any curious data person should do and analyzes 2022 analytics blogs. It's a good exercise, because it highlights for me some things I'd missed and that you, dear reader, shouldn't want to!
A side note: Almost all of the top 10 come from SAP folks. I've noticed that it seems like a huge percentage of the SAP community blogs come from SAP employees these days. I don't know whether that's right. Where are non-employee people doing their SAP-focused writing these days? Has it moved into more of the personal spaces, or even spaces like this substack?
Highlight on SAP's AI portfolio. I think SAP has, generally speaking, adjusted their AI/ML messaging to focus on the benefit of the AI rather than "this product has AI in it!"-type marketing. So it is nice to see a collection of the technologies and services that underpin much of the AI activity. When I think about the absolute latest, cutting-edge AI innovations and their place alongside business data, I still think the hottest action will take place outside of mega-frameworks and enterprise-tuned services. Scenario-based innovation seems to move faster than productization.
Analytics Cloud and Data Warehouse Cloud: key feature overview. This is just plain good. It matches overall features with some nit-picky details you might need to know when implementing these features. Informative and useful.
I cover lots of blogs in this newsletter (this issue and others), and I want to sincerely thank the authors of blogs for taking the time to set their thoughts down. It is NOT easy to go from a mental representation of a topic to a coherent, helpful writeup. PM
Refactorers Anonymous
The subject of code refactoring is of the “Mac vs PC” controversy and divisiveness level. Some developers avoid refactoring at all cost but some join Refactorers Anonymous club where the answer to “how much to refactor?” is always “yes!”
Refactoring seems to contradict the main development rule “If it works don't touch it”. Because it is “behavior preserving” and is meant to improve the design sometimes with no visible benefits, it’s typically not supported by the management. Does it fix a bug or add a feature? No? Then why even bother?
In his excellent presentation Refactoring Is Not Just Clickbait, Kevlin Henney explains why developers refactor code (“it haunts us”) and why refactoring doesn’t necessarily mean someone has written “bad” code. Writing code means expressing ideas and ideas can change over time. Some code could’ve been fine when written but the world around it moved on. Software is “soft” for a reason. (My POV is that programs are more like living organisms than marble statues.)
Back in SAP land, in Refactoring Legacy ABAP Code, Paul Hardy writes that legacy code is the one that doesn’t have unit tests. He goes into great detail on how this could be addressed by creating your “isle of happiness” in the sea of legacy. This makes sense because you need unit tests to make sure further refactoring doesn’t break anything. Having unit test coverage should probably be the ultimate goal for ABAP developers. But realistically, nothing clears the room faster than mentioning that you should not just write the code but also the unit tests for it. Yikes.
I’m a big fan of “baby steps” when it comes to refactoring. There are plenty of refactoring methods that you could start using today to make the code a more habitable place for everyone. Doing nothing to improve the code is a bigger mistake than not writing unit tests. Bring on the angry letters! JP
CompSci With ABAP
ABAP developers: it’s OK. You don't have to take all that abuse from your colleagues who use fancy-schmancy languages like Java and Python for their application work. Don't listen to the haters who studied some kind of C-based language for their vaunted Computer Science degrees. You have, at your command, a language that is equally suitable to express complex algorithmic solutions to fundamental issues in that field.
Prabhjot Bhatia believes so, too, and explores some programming fundamentals in his series "Data Structures and Algorithms in SAP ABAP". He hits it on the head: "Why should non-ABAP developers have all the fun?" He goes through a couple of problems like "given an array of integers of size 'n', find the maximum sum of 'k' consecutive elements in the array" - the kind you probably won't encounter when you are making yet another purchase order approval app.
I love this! I'm a fan of ABAP; among the other languages I love, like Python, JavaScript, and C#, ABAP has this unique wordy quality to it that makes it readable and expressive in its own way. I hope this newsletter is a safe space to admit liking ABAP. PM
Support the Nerdletter
Please keep the humble enterprise nerds in your hearts. A cup or two of coffee really helps us keep the Nerdletter going.
Thank you for your continuous readership and support!
 | A guest post by
|