A few weeks ago, when I announced my first SAP publication, “ABAP Development for Sales and Distribution in SAP”, I promised a post in which I delve a little deeper into the book, its background and how it came about. A little “behind the stage” article if you like.
One of Pixelbase’s main mantras is very much to “Keep it Real”, to provide value for money and real-world advice. It probably might not come as a big surprise to you that “ABAP Development for SD in SAP” was written along the same lines. In order to achieve a certain “real-world feel”, I decided to create end-to-end examples and use two characters (Junior ABAPer “Christine” and Senior SD Consultant “Sean”) and a fictive company (“Byrell Corporation”). While Christine is a young developer, well-versed in topics such as OO programming, Sean is an experienced SD consultant who occasionally dabbled in ABAP, but has never created a class parameter in his life!
Believe it or not, even a seasoned SAP Development Consultant like me has more than a handful of dreams left when he sits by his ABAP campfire in the evening. One of my many thoughts has always been around making the user interface (UI) of traditional SAP applications simpler. This process is often described as “Screen Simplification”.
SAP Personalisation and Simplification
Over the last 15 years or so, SAP has been working very hard to provide tooling to make a certain level of personalisation easier. Personalisation, Transaction Variants, GuiXT, Screen Exits, Screen Enhancement BAdIs and –in more recent years- the ill-named Floorplan Manager (FPM) were one of the vast number of attempts by SAP to make the building process of friendly user interfaces simpler and easier. Read more
Some of you might have noticed that I neglected this site a little recently. However others of you might also remember that some time ago I vowed to come up with new stuff. Well, the time has finally come to reveal what the prolonged silence was all about.
I have written a book! Back in October 2011 I began talks with Kelly Harris of SAP Press about a technical book for the Sales and Distribution (SD) module of SAP ERP. A lot of emails went to and fro across the Atlantic, discussing content and format, but by Christmas 2011 I started writing.
My book will be published by SAP Press in
September October 2012 and is called:
ABAP Development for Sales and Distribution in SAP: Exits, BAdIs, and Enhancements
If you are a beginner to intermediate ABAP developer, functional SD consultant, application architect or involved in a SD project then this is the book for you. In a real-world approach, it will introduce enhancement methods to you and compare them, so you understand the pros and cons. With this book I am hoping to give consultants a better understanding of the enhancement process (how to find enhancements, choosing the right method, implementing them properly).
You can pre-order the book now from the SAP Press online store, but I’ve been assured that there will be many ways to get hold of it once it has been published.
There’s a lot more to report, especially on the process of writing. Once published (October 2012), I will talk more about the book and how it came about.
Can we please stop talking about “creative programming”?
Many years ago, I had a cartoon pinned up by my office desk. It was a caricature of a pianist-like dressed man, sitting by a PC. Over the course of several sketches he got more and more excited, hitting and bashing the computer keyboard in ecstasy. The final frame showed him throwing back his hair, a satisfied smile on his face. He seemed exhausted, but happy. Alone, yet in awe of his work. Underneath the cartoon it read in German: “Der kreative Programmierer” (the creative programmer).
Fast forward to 2012 and this cartoon of the creative programmer appears to be more alive than ever. I have had it with tweets/posts/articles telling me about “creative programming” or something close to it. In my world, combining the words “programming” or “coding” with “creativity” does not compute. I find it also not helpful, because it gives the wrong impression to aspiring software developers as to what is actually involved in the task. You are not sure? Well, bear with me a little.
Welcome to my world
When it comes to development of business applications, best practice is to either have a design, a specification or some sort of document that tells a programmer what is required from him or her. It’s what comes out of the analysis phase. Such a specification is the cornerstone of business application development, because it is a contract between the people that requested functionality (you might even replace “functionality” with “app” here) and the ones that cut the code for it. Believe me, if you are an IT department, without such a document or agreement, you will spend too much time and money getting your developments right. If a specification or design is done right then the programmer should know pretty well what to do. There is no programming creativity required anymore at this stage, the program should cascade from the specification. In addition, there should be a standards document that gives the programmer information about naming standards, how to structure your code and how interfaces should look like, for example.
If you now say that specifications never live up to the detail they ought to contain in a perfect world, then I say: this should not be ironed out by a creative programmer, who goes away and does his or her own thing. If a specification or analysis document is below par then this reveals a poor development process in general, which has to be resolved upstream and at the source. Otherwise it’s like compensating for a bad golf swing by simply moving your body to one side. It’s lazy.
Saying this is of course not very fashionable and snazzy, especially with all the innovation hype that’s pumped out by today’s software corporations. These days, every software developer who is seeking success is easily sucked into thinking that in order to develop the next Instagram or Twitter, you have to be perceived as out there, creative, getting it. Here is the kicker: as far as the pure programming is concerned, you need to stick to agreed rules.
Am I saying that no creativity is involved ?
My answer: Far from it. But here is my criticism: No one seems to say that coding in itself is not the creative part of developing software successes. From my own experience, successful software projects are based on all or a combination of these points:
- Good, successful software is a team effort – this has always been the case in IT history and is not a new paradigm
- Analysis and gathering requirements with the actual users is important because that’s where you ensure your product doesn’t suck. It’s where you listen.
- You never design or specify software in a vacuum. Respecting boundaries (budgets, software platforms, languages, your customer etc) is important. It’s also an important difference to the work of artists, who are not limited by boundaries.
- If you develop in a team environment, you need standards and agreements that go beyond the daily programming and span entire projects.
- Finally, coding requires focus and discipline. You need to stick to what has been agreed and specified. In some cases, this is one of the last steps of a long software development journey
Just a human brain and a machine
Of course, you can sit at home and hack away to your heart’s content. I deeply encourage you to do so, because it is great for learning. You might conjure up some cracking prototypes, something that combines technologies and will be the foundation stone of IT’s future. You will still be restricted many things, but this probably is the closest to creativity you can get. It’s just a human brain and a machine – I know this can be thrilling, for sure. It might be the first of a million baby steps towards something new, but it does not resemble the creation of something that is scalable, timeless and profit making, which are the hallmarks of successfully designed software.
Successful software is brought to life not by creative programming, but by listening, analysing, negotiating and (in the end) coding and sticking to what people have agreed on. Coding is a skill, not a talent. Power needs control.
By the way: I’ve been trying to dig up the mentioned cartoon, but can’t hunt it down. Please contact me if you have it or can get hold of it.
Some of you might have seen Hugh McLeod’s picture about producing something “amazing”.
As it happens, today I had a work discussion that touched on just that. We were faced with the choice between something that ticks the “timescale” and “achievement” boxes and something that ticks the “appealing” and “users will love it” boxes. Suffice to say what the obvious business decision was… once again, Quality was Job One.
I see this at a lot of SAP sites. The implementation team knows that users are not particularly happy with the system, but everyone seems to be getting their work done, so why do things different? The SAP team therefore focusses on the measurable part, the quality. They might even say: “Hey, SAP is standard software after all. If you want to have fun, install Garageband on your own machine at home!”. I used to say that, too. But not anymore. Because things have moved on.
So here are some key points to all of those who oversee developments and have the power to decide whether a development should do same-old-same-old or push some boundaries:
- trust your senior developers, let them “loose” every now and then
- use prototyping to explore new areas once in a while
- not everything has to be done in SAP GUI (or downloadable into Excel, for that matter)
- send your team to events such as TechEd
- have the guts to defend your team’s efforts and ideas in front of your superiors
An interesting conversation was sparked off by this tweet today:
My response to this was:
if you work in a department that has time to revisit code then somethings wrong, too. I rarely get that opportunity.
To round it all off here was Ethan Jewett’s response:
Disagree. Something is very very right in that case. Question is why it never happens in SAP space.
Within Enterprise Software, one important thing to keep in mind is the purpose of the project you’re working on. A lot of my work focusses on Enhancements and Exits in standard SAP modules, another sizeable chunk is in bespoke SAP developments. Whilst the latter tend to be rightfully graced with more design thinking, Enhancements and Exits are very often “one shots”. A functional consultant and /or myself perform analysis and risk impact, implement the enhancement/exit, develop the business logic and test it. Once the work is done and does the job as intended, everyone is happy.
Bigger fish to fry?
Now, some time down the line the code for this enhancement might become dated. This can happen if syntax, tooling or standards have improved. But unless there is a pressing business reason to change the coding, everything is kept as it is. More than often there are good reasons for this: Additional development overhead, new developments, upgrades and the ever-popular regression testing are only a few things that spring to my mind. A keen developer might look back at his code in anger, but let’s not forget that code stability is also important in business. What if your code might be up to scratch with the latest release, but fails to create the invoices it is intended to do?
Does it mean that ABAP development leads should not -even for smaller enhancements- preach things such as OO-thinking, reusability, peer reviews and unit testing? Far from it. In times of shrinking budgets and shorter implementation times it is even more important to apply more design thinking, improve your dev teams skills base and promote better team communication (because that’s what it often boils down to).