Just a quick note to point out an exclusive $100 discount by SAP Press to independent SAP Consultants.
Jon Kent just tweeted that freelance SAP Consultants are given a discount when purchasing one of their Annual Subscriptions, giving readers access to their entire online library and allowing to search and print pages, download code examples. This would obviously also include my book.
Currently, the price for an annual subscription is $999, making it $899 for independent consultants.
If your annual bill of SAP book purchases has sky rocketed or you need the convenience of accessing the entire library for the next 12 months whilst on the move then this might be an option for you. (Offer ends April 30th 2013)
… please come and say Hello. I might be deep in conversation, thoughts (making sense of it all) or have my nose in a Latte. In any case, please feel free to interrupt for a chat. You’ll usually recognize me by my SAP Mentor shirt with the “@Pixelbase” Twitter handle and the number “70” on the back.
If you don’t want to talk to me then you can still go and discuss all things SAP with any of the other mentors. Believe me, these guys and gals feel as passionate about SAP as you and we are always interested in your views.
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.