Today I open the traditional ceremony by watching my all-time favorite movie again: The Graduate. Young Dustin Hoffman’s debut from 1967. I have watched this movie a hundred times in the meantime, but I can always enjoy it again: The dialogs are hilarious, the whole visual appeal of the movie is timeless and the cuts are just brilliant! Anne Bancroft, Katharine Ross and Dustin Hoffman are awesome… The soundtrack from Simon and Garfunkel is a classic!
I first watched the movie back then when I was still in school and later when I went to university. They played it regularly in a cult movie theater in Heidelberg. That’s when I fell in love with something else in this movie: Dustin Hoffman’s little red Italian car: An Alfa Romeo “Duetto” Spider! Funny how Benjamin (Dustin Hoffman) is following his true love Elaine throughout California in the movie, riding through beautiful Californian scenery, crossing Bay Bridge in San Francisco, making his way from Los Angeles to San Francisco, to Berkeley, trying to gain her love…
While being at university in Karlsruhe, I had a night-time freelancer programming job at a startup company in the middle of nowhere, Germany: A company called SAP, located in Max-Planck-Straße, Walldorf, that at the time had an already impressive number of employees: around 500. While most of my colleagues at the time were still working on a mainframe system called R/2 and there were just first steps made towards a client/server-based solution called R/3, I was the “PC guru” who was programming frontend applications to visualize and provide drag&drop modification of org charts in the R/2 and later R/3-based HR application. As you can see, the company was already back then visionary enough to identify the constant need for a tool to help companies to flexibly reorganize 😉
Anyhow, it happened that a colleague of mine at the time was driving one of the successor models of this Alfa Romeo Duetto Spiders: A black one, with some fashionable 80’s plastic spoiler that Pinin Farina must have designed onto his otherwise perfect design in a moment of total derangement. But in the end, it was the car I needed to get and when the colleague decided to sell it, I become the lucky owner of an Alfa Romeo Spider! Who cared about this plastic spoiler… That’s how it happened that in the following 12 months, you could see happy me and a friend of mine, both Computer Science students at University Karlsruhe at the time, ride with a big smile hammered into their face, wind blowing around their head with the top opened, to Karlsruhe every morning to follow some lectures at University, and back to Walldorf in the afternoon to start their second life as freelance programmers at a company called SAP over night… We had a great time back then…
The fun lasted 18 months roughly, until a strange and seriously concerning rumble from the rear axle convinced me that Italian convertables are perhaps not something that a Computer Science student with just a nighttime job should really invest into. So I sold the car before it became an expensive investment ruin.
But the dream about an Alfa Romeo Duetto Spider, the original from the 1967-69 period, the one with the round tail, nicknamed “Osso Di Sepia”, remained with me for years. Like the tradition to watch The Graduate over and over again whenever it was played in the movie theater in Heidelberg…
Finally, in 2002 I decided to go get a Duetto. I started to browse various oldtimer forums, online used car sites and travelled Germany in search for my Alfa Romeo Spider. After quite a number of disappointments and learnings, I made the one out. My Duetto. A 1969 Alfa Romeo 1750 Spider. Born 1969. White. Reasonable condition. Some minor things to fix, but otherwise original and in good shape. A re-important from the US. It seemed we had been in search for each other. And there we finally got together… Lol!
And now, every year since then, there is this tradition of me watching “The Graduate” again a few days prior to April 1st, when my Alfa Romeo Duetto gets out of its garage after winter. She gets hibernated in October every year, covered with a blanket and on April 1st, no matter what weather the day happens to bring, I carefully lift the blanket covering her, send a prayer towards heaven that oxidation has had shown empathy with us again this winter and there’s not just a small pile of rust on the ground left of her, and after some de-hibernation and cosmetics, we go for our first rendezvous of the year… The top open, the sun above us — keep your fingers crossed –, the wind around us and attitude clearly being that this will be our year again… Get out of our way, ’cause here we come… The only living boy in…
Six days to go. Six days…
Mr. Braddock: Ben, what are you doing?
Benjamin: Well, I would say that I’m just drifting. Here in the pool.
Mr. Braddock: Why?
Benjamin: Well, it’s very comfortable just to drift here.
Mr. Braddock: Have you thought about graduate school?
Mr. Braddock: Would you mind telling me then what those four years of college were for? What was the point of all that hard work?
Benjamin: You got me.
“If you don’t know what you are doing, don’t do it on a large scale.”
We all experience it many times every single day. With italian cars that just won’t start in the morning. With Exchange Calendar appointments that simply disappear. With mobile apps that just won’t connect to the Internet when we need them. With auto-correct features in email clients that changed some words in your email in a career-bending or relationship-ending fashion without you noticing before you pressed the send button.
What I refer to is the bitchy randomness at which technology failures light up our days. Light up in flames. And like with all things people love from the “consumer space”, the expectations rise also towards the so-called “enterprise space” to follow accordingly. That’s commonly referred to as “consumerization of IT“.
Over the past months and years, we got painfully aware that even in ABAP the developer community has become comfortable with the status quo, complacent almost as to how easy and predictable it is to quickly code a new application to serve your employer’s or contractor’s needs. Far too easy, we believe. We all feel that it has to remain a certain science, wizardry, black magic to understand how a computer program actually works. And it has to feel arbitrary to some extent. Like bringing up your kids.
My team got notice of this burning issue already some months ago, but it took us a while to build up the necessary sense of urgency around it. And luckily, with Design Thinking, we got the tools at hand to really confront the problem heads-on. How could we bring the random malice of the consumer space experience to enterprise computing? What we came up with is simple but effective. As always.
After building and pushing around a fancy straw prototype of the solution in a Design Thinking session, we decided to introduce the
COME FROM statement in ABAP. It contrasts with the
GOTO statement, which for good reason has been considered as an approach too naive to effectively confuse programmers by acclaimed computer science legend Edsger W. Dijkstra already in 1968, as it does not impact the control flow of a program by telling where to jump to in execution, but rather tells where to come from whenever program execution happens to pass the given source code location. It started as a notion, but we quickly turned it into an ingenious idea and then into a brilliant concept. In particular if one looks at the additional attributes that one can add to the “come from” statement:
COME FROM [WITH PROBABILITY <expression> ].
where <expression> can be any valid ABAP expression yielding a floating point value between 0 and 1, or whatever else at which the execution is not determined at all.
As common sense implies, the
COME FROM statement will be executed with the given probability, resulting in the programm execution continuing in the first statement following the
COME FROM statement or continuing at the statement at the <source code location>.
Without thinking for too long, even the most junior developer will realize what enormous excitement such statements can bring to otherwise trivially boring code.
In a relentless effort to bring unnecessary reduncancy into the set of ABAP language features, we have also decided to introduce a new statement for execution blocks:
SKIP. <statements> END SKIP [WITH PROBABILITY <expression>].
The careful observer will have recognized our villainous brilliance to move the probability expression to the end of the
SKIP execution block in order to further reduce code readability.
We plan to introduce these new ABAP language features with SAP NetWeaver 7.4 after some more intensive validation with customers.
With SAP NetWeaver 7.5 we will then provide a set of new capabilities in the ABAP development tools to improve the effectiveness of the new statements above.
First, we will introduce what we call “progressive obscurity” in the “ABAP for Eclipse” editor: with this feature you can — based on personalization of your Eclipse settings — determine whether the editor shows or hides the
COME FROM statements from display. This adds enormously to the fun during professional code review sessions. We are also testing whether randomly hiding normal statements outside of
SKIP blocks could further help to confuse code reviewers.
Second, we will add support for the above statements in the ABAP Debugger and the ABAP profiler, which will be enhanced with predictive code execution capabilities built right into the tools themselves interfering with the underlying runtime Virtual Machines.
Obviously, all of this is only a stop gap solution to bridge the time until the probabilistic behavior has been pushed further down the stack into the hardware itself. We have started to try to convince major CPU/MPU builders like Intel and AMD to add the above features to their hardware designs yielding utmost performance in randomness.
We understand that such a hardware driven approach will take some time to be ubiquitously available in all IT landscapes. We have therefore triggered efforts with Operating System makers to provide software solutions to the market that already today bring the benefits of random behaviour to end users. Solutions include TCP/IP drivers, DNS and DHCP servers, network domain login modules, Exchange server modules and file system drivers that will show arbitrary failure and outage behavior.
A renowned IT analyst company, that wants to remain unnamed for unspecified reason, has estimated the 2017 market for such solutions to exceed 37 billion US$ in total. While we consider the market significant, we have certain concerns though how much of this market we can actually tap into with a standard software solution, as corporate IT departments already today seem to have deployed partial solutions for random infrastructure behavior. At least that’s what we deducted from end user reports we’ve evaluated.
Patents are of course pending.
Hope is at the horizon. The days of waiting are numbered. With probability 0.5.