#55 ABAP Wordsmithing, Dev Tech Radar, Women In Tech 2024
In this issue:
Put SAP Dev Tech Radar On Your Radar
Are you wondering what SAP technology has any future and what should be sent to the farm upstate? Behold: now we have a “buy / sell / hold” stock market equivalent for SAP professionals in this SAP Developer Tech Radar.
Not only that but everyone gets a chance to contribute suggestions and participate in heated discussions on whether BRF+ is dead or not quite yet, for example.
One great thing about this “radar”: it’s not an official SAP resource. Therefore you won’t find SAP BTP as “answer to universe and everything”. Another great thing: there is an explanation behind each item. And there is more! If your team suffers from “that’s how we’ve done it for 20 years and it works, why change anything?” syndrome, this will help you to see the light. Short story even shorter: go bookmark it, join discussions, and spread the word. JP
ABAP Loves Words, And I Love That
I find ABAP prosaic in the best sense. The wordy style makes me feel like I’m almost reading prose when I read programs. Jumping in as a beginner or as a sometime-analyst just looking to find an answer, ABAP really does make it a little easier than some other languages to just…read and understand.
The key to this wordiness? ABAP’s huge keyword list. So I got curious: which languages have the most keywords? This survey doesn’t include ABAP, but if it did it would find that ABAP has easily twice as many as the listed leader, Visual Basic.
In celebration, I’ve written three pretty bad haikus (and had Gemini Ultra write two more) - comprised entirely of ABAP keywords. Enjoy! PM
// loss
TYPES CAST ALL COPIES
FIELD-SYMBOLS SHIFT IN PERFORM
STRUCTURE IS EMPTY// sorrow
CODING COPIES BASE
1 HANDLER, 7 SYNCPOINTS
TRUNCATE MEMORY// heart-war
ALIGN ATTRIBUTES
DEFINE EXCEPTION-TABLE
BREAK ALL CHAIN-INPUT// joy of life (by Gemini Ultra)
WRITE COLOR GREEN
FIELD LENGTH GRANT LINES PLUS
DYNAMIC LOOP RUN// sorrow (by Gemini Ultra)
IF LINES END CASE
SELECT EMPTY FROM OUTPUT
FIELDS VALUE VOIDWomen In Tech: 2024 Edition
March is Women’s History Month and also the time of year when I get to play my “lady card” and write a story like this one.
It’s hard to believe this great article by Rachel Thomas is almost 9 years old: every word of it is still valid. Thankfully, there has been at least some progress since 2015. For example, Rachel wrote “don’t emphasize face time”. Despite some desperate RTO calls (brought to you by the local commercial real estate mogul), I think we’re finally moving on with remote and flexible work as the new normal. Women are not the only beneficiaries of it but not having to schlep to the office daily has been a bliss.
This is the most highlighted quote from the article:
“If tech culture is going to change, everyone needs to change, especially men and most especially leaders.”
I hope that we can plant this idea into more and more people minds that “lady issues” cannot be solved by women alone. Good friend Jamie Langskov said it best in our Nerdcast episode:
“It’s really on our allies who have some pull, some influence to speak up for us. That’s why one of my big things is sponsorship over mentorship. You should be putting yourself out there to elevate someone else […].”
When playing my card 2 years ago, I thanked women in IT for showing up. Now it’s time for those who claim to be our allies to show up as well. JP
SAP.iO vs. Math
SAP.iO Foundries recently concluded operations. I'd written about it previously, and still would occasionally go check out the action there. I feel connected to the folks who go into startup programs like that, as I've worked at a few startups over the years myself.
It seems like running a program/incubator shares many of the struggles of the startups it incubates. Most notably every business's chief adversary: math. The bills come due, the investors have to make a return, and you have to pay people. I don't know any inside stories, but if I follow this chain of phrases:
"Years of driving exponential growth for enterprise startups from across the globe"
"The strength of this market-leading ecosystem"
"The SAP.iO portfolio has yielded 5 unicorns, 70 exits, 42,000+ jobs created in 45 countries, and $12.9B+ of cumulative VC funding raised"
To this:
"SAP.iO Foundries concluded its operations on March 1, 2024"
It's pretty clear that math won the final victory. PM
PS - I captured the portfolio listing in a spreadsheet for posterity, in case the website goes dark.
You Should Actually Test Stuff
I had the chance to watch a live demo of UFT One, specifically its new-ish AI features. Having worked a few projects that involve automated testing, the demo reminded me of a few pain points I’ve observed over the years. I can’t claim to be an automated testing expert - but I’ve been in the room when those people work their magic, and I saw what I saw.
If I was in the market to buy automated testing software, here are the top features I’d be looking for.
Writing tests sucks. Anything I invest in would have to make it so that the folks creating the tests don’t put ancient curses on my household.
Automated tests are fragile. They need SO MUCH maintenance. The suite I invested in would have to make it so that the tests could survive minor tweaks and enhancements to the software we’re testing.
Automated testing goes out the window at a certain point because needs are flying fast and furious, while time is dwindling away. My money would have to be spent on something that can produce new tests fast.
Many applications have both a frontend and a backend worth the while of testing. My chosen suite should include the power for both fuzzy UI and structured API testing.
This isn’t an endorsement of UFT One. I haven’t personally tried it. But I am seeing big projects struggle with automated testing. It’s head-smackingly obvious that those projects would benefit enormously from automated testing done right. PM
OOP Video Recs
It’s getting more and more difficult to avoid the over-produced videos of some guy who worked at <insert well-known tech company> but now spends days pontificating about OOP while selling 300$ microphones. And even the good YouTube channels are plagued by the thumbnails where the creators make their best impression of Edvard Munch’s painting. But it’s still possible to cut through the noise to find some useful nuggets.
My find number one is The Problem with Object-Oriented Programming. Surprisingly short (one could easily rant about the OOP problems for hours), it touches on my favorite “too much abstraction”. If you’ve ever tried to figure out why SAP Gateway sent your request via specific path and stumbled upon hundreds of interfaces with no actual code behind, you know exactly what I mean.
Second find is this interesting video from Zoran Horvat about method chaining over nested calls. His code examples are not difficult to understand even if you don’t know anything about Microsoft Jav…, I mean C#. And many of the same challenges would apply in ABAP. Great tip from this video is to consider how does the code read like. If it sounds unnatural, then it probably not good.
Are there any developer YT channels you recommend? Drop us a comment! JP
Watch the corresponding Nerdletter Talk for bonus content and discussion.
Don’t miss new episode of The Boring Enterprise Nerdcast! We sat down with Dominik Panzer to talk about the horrors of Agile and Scrum and play a fun game.
Nerd sighting in the wild: see Jelena present in person at ASUG Carolinas chapter meeting in Raleigh, NC on March 22nd.
Please consider supporting this Nerdletter by buying us a cup or two of coffee. Thank you for your continuous readership and support!
OOP is at the core of most problems of the industry.
I am not a developer, but I work with closely with developers von 2 decades. Normally I wouldn't care what paradigm developers choose. However, when they started OOP in ABAP things went downhill. Development times went up. Code quantity went up and code quality went down. Design patterns which solve problems of OOP but solve zero problems of outside world became fashionable. Now developers could spend their working time in boilerplating the same design patterns over and over again without solving the users problem and being confident of their competence at the same time (which in my sense makes OOP so attractive for developers).
"This can not be changed anymore" became a more common problem than in the times of imperative programming. Presumably mostly because the object model would have needed to be refactored before implementing the change or the carefully selected design pattern du jour did not fit. "Refactoring" is anyway another problem only introduced by OOP.
With OOP code became more obscure, complexity of runtime behavior became high, debugging more difficult, hence more bugs. Since it became increasingly impossible to create reasonably bug free code, mandatory tests were introduced to solve next OOP related problem. It is generally a bad idea to test quality into a product instead of trying producing good quality from the beginning. But here you go.
10 years ago, I spend 80% of my discussions with developers on business need. Nowadays I discuss 80% of time technical issues. The absolute amount of time spend on the business needs did not change though.
OOP is an expensive experiment which needs to end. Only that SAP came to the idea to make in mandatory.