… 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.
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.
At a time when lots of my Mentor colleagues are at SAP’s internal DKOM events, I had the opportunity to attend SAP’s semi-public UK Technology Forum in St Albans on March 21st and spent day 1 there, mainly focussing on information around User Interfaces and Netweaver Gateway. As a regular TechEd visitor, events such as this are not providing you with a raft of new items around SAP products, but instead give you with a gut feel for the local customer and developer community.
I have yet to see this evening’s Demo Jam, but so far it’s been a worthwhile trip, which is mainly down to networking and chats I had. Here are my key points:
User Interface and User Experience: demos and presentations were around HTML5 – either driven by Sybase Unwired Platform or developed straight using HTML5 and CSS3. For example, Keytree demoed an interesting live retail app for iPad that uses HTML5, hooked up to a SAP retail backend via homebuilt RESTful services. CompriseIT demoed a new SAP tool to generate native iOS consumption UIs for Netweaver Gateway services.
Gateway: I liked that most presentations clarified that not just SUP can be used for consumption, which was in contrast to information available during TechEd 2011 in Madrid, where participants often thought SUP is the only way to consume Gateway. I attended two interesting sessions by SAP labs’ very own Yaad Oren, including a Kinect-enabled Gateway solution and a Siri-based prototype called SiPi (using Open Ears). In the latter, a video showed a SAP CRM lead being created using iPhone voice recognition and later an image was added to the CRM business partner by searching the person on Facebook, based on facial details. This is a very likely future use-case, yet it still makes me slightly shudder! (Disclaimer: the app is only a prototype!). As far as a wider developer engagement for Gateway is concerned, it seems that a reliance on the SAP partnering framework is the chosen path for now. Whether this will hamper the “billion users” ambitions SAP has remains to be seen.
… and you spot me either rushing from session to session or in deep conversation with someone, I urge you to interrupt me for a chat. You’ll recognise me by the “@PIXELBASE” Twitter handle on my SAP Mentor shirt.
Independent SAP Development Consultants like myself can be less influenced by the latest trend and fashion, because our work is very often based on current customer project requirements. I therefore tend to be more pro customer-side, trying to “keep it real” and end-user relevant. Having said that, it’s also important to get a glimpse of the future and accustom yourself with upcoming products. That’s one of the reasons why we’re all going to TechEd.
One more word with regards to SAP Mentors: We’re a groovy bunch, but just because we’re Mentors doesn’t mean we know everything. SAP Land is a vast space and not one single person can claim to have the complete knowledge. And to be honest, we don’t have to, because we are a passionate, open, collaborative and extremely communicative team. Believe you me, we can talk for hours about SAP stuff.
If you have a question about Mentors, our initiatives or you even want to chat about something that bugs you, then let us know. We can be quite critical about SAP and its products, too and we’d love to hear your constructive thoughts.
And most of all…. HAVE A GREAT CONFERENCE !
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
Fellow SAP Mentor Vijay started an interesting post series on Offshoring and Outsourcing over on his blog. His first edition deals with a little bit of SAP Offshoring history. A trip down memory lane so to speak. Vijay provides some very interesting insights into an industry that has seen a lot of growth in recent years, but is also slated for not always providing best value for money.
Nowadays outsourcing of SAP resources has become commonplace. Standards and SLAs have improved the overall service provided. However I have yet to speak to a client who wholeheartedly loves it. Most of them do it, driven by cost pressures, not conviction or deep belief in its merits.
As mentioned in my comments, I compare it to the big mains gas or water utilities that bring in expertise to deliver a service to your street or door. Skilled in-house teams or freelance resources then get it into your home.
It’s not what outsourcers will tell you, but it’s what my experience has shown me.
I’m looking forward to the next instalments.