Why I think coding is not creative

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

What is my world? For those who do not know me, I have been a SAP Development Consultant since 1998, who mainly programs in SAP’s proprietary language ABAP. There are other languages like Javascript and Flex I sometimes need to use to get my work done, but ABAP is what SAP’s applications are mainly based on, because that’s what you use to code business logic for a SAP system. It’s what this language was made for. However what I am saying is universally applicable to any programming language or development environment. Depending on the projects I work on, I also get perform analysis and gathering of requirements.

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.

 

SAP Development: having the guts to be great

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
If you have been affected by the points raised above then please feel free to come and chat to me about it at SAP TechEd Madrid next week.

Looking back at your ABAP code in anger ?

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).

 

SAP from the Apple tree

This post is predominantly for those people in the SAP development community who lament the news that Apple has decided that with iPhone OS 4 any 3rd party dev environments are kicked off the popular mobile platform.

If you’re an accomplished iPhone developer who largely focussed on Adobe’s Flash-To-iPhone compiler or tools such as MonoTouch (both of which I do not know or have used, by the way), then I can actually understand your anger.

However, if you are a developer who lives and breathes the SAP ecosystem -and ABAP in particular- then this whole epipsode must sound to you like a sequel of “Back to the Future”. Apple’s move aims to create a development platform which is dominated by the one and only language Apple (who actually developed the platform’s hardware)  sees fit – Objective-C. Parallels to SAP’s own proprietary language ABAP are not out of place here.

I’ve recently dabbled a little with iPhone SDK and even though ABAP and Objective-C are not very similar languages by and stretch of the imagination, what they do have in common is that their respective “inventors” push these languages for reasons of stability (a strength of both SAP’s ABAP stack as well as the iPhone OS), reliability and performance.

For years now, SAP’s ecosystem has been mainly hailed for its rigid design under the bonnet, the bulletproof-ness, the stability. At the end of the day, vast numbers of global businesses rely on SAP’s technology day in day out. ABAP, love it or loathe it, plays a central part in that. (It also plays a central part in which future path for SAP to turn towards and innovate the core, but that’s another topic).

Maybe it’s because I’ve been using stable Macs for 15+ years now and been part of SAP’s ecosystem for many moons, but why is it so hard to understand that Apple is trying to provide a stable and reliable platform for iPhone, running on hardware Apple has developed itself? I’d wager that the same people who now complain about the locked-down dev platform would also be the first who would complain about crashing iPhone apps had the device not been so tighly regulated.

an ABAPer’s journey to Netweaver CE (#2)

Let me give you an update on my journey onto pastures greener that are the SAP Netweaver Composition Environment (CE). If you’ve missed the first part of this series, go, go, go and catch up now!

“I find your lack of faith disturbing.”, Darth Vader (Star Wars)

Over the past 2 weeks, I’ve spent a lot of time in SAP’s own Enterprise Services Workplace on SDN, which is a pretty good resource to look through SAP’s latest enterprise service offerings. It’s actually more than that: it’s THE place where you can find up-to-date info on documentation for services which you deem appropriate for consumption or exposure in your own landscapes. On their SDN website, the ESW is described as follows: “The ES Workplace is the central place to view consolidated information about all available Enterprise Services delivered by SAP.”. Fair dos.

You can install an ES Repository yourself, but chances are you’re not always on the latest release, so checking the ESW is always a good way to see what’s around the corner.

Now you would think that the ESW gives you an easy overview of the services on offer, describing to you exactly what each service does (especially when you compare them to each other). You would probably also think that the ESW gives you a nifty little search engine which enables you to sieve through the 2000+ services and get what you want quickly.

Well, things have definitely improved and especially the testing part of the service (against SAP’s own Discovery System, ie an ECC app stack) is much better now. However much is still left to be desired as far as documentation, search facilities and test harness is concerned. Oh, and while I’m at it: don’t even think about opening up the ESW in browsers such as Firefox, Safari or Opera.

Luke Skywalker

It simply looks to me as if these services have been arranged in such a way so they fit well together with SAP’s module documentation and education plans. This doesn’t always sit in line how other consultants look for services.

In contrast, here is the way how I approach a service from a developer’s perspective: I know I want to create a sales order in a backend system. From my old BAPI days I remember that I need a few parameters to feed the service in order to get order processing going without those elusive error messages. You can find the “Sales Orders Create” service easily enough, but of course that’s only part of what’s needed. If you’re looking around for services to find sales organisations, sales groups, divisions et cetera, you’ll be surprised how difficult it can be to get the information out of the backend that you’re looking for. Bottom line for me is: finding the services you require and testing them is still far from easy.

“Once you start down the dark path, forever will it dominate your destiny”, Yoda (Star Wars)

Now as a developer there is an underlying danger in all this. Let me tell you what this is: The more time you spend looking for those services and collecting your data, the more you’re inclined to log into the backend using SAP GUI, enter the letters “S-E-8-0” into the top left of the screen and create a little remote-enabled function module, expose it as a web service (using a wizard) and get those pesky sales order related details out of the ERP system. Even worse, you’re even contemplating copying a SAP standard function module to extend it so it does what you want it to do. Do not give in to the powers of the dark side….

Now can I just say one thing here: I bet there are other ways to retrieve data out of the backend system. Whilst I love to hear about them, all I want to illustrate here is that I’m currently on a long journey during which I will learn how to find the services I require quicker and get the backend to do what I want it to do. The benefits will be that the customer I work for have systems that need less support and testing after an upgrade, because services to external systems are provided via standard services which are constantly updated and maintained by SAP.

However a little help from SAP by making the ESW easier to use wouldn’t go amiss!

TO BE CONTINUED!

an ABAPer’s journey to Netweaver CE

SAP Mentor Yoda

SAP Mentor Yoda

“You must unlearn what you have learned.”, Yoda (Star Wars)

Heeding Yoda’s advice, I’m currently in the process of unlearning some (but by far not all!) of the skills I’ve acquired over the years as SAP Development Consultant. During the past 11+ years, I’ve developed a lot of my applications within the ABAP stack, mostly for use within SAP GUI, sometimes within a browser.

Now, to some of you this might sound a bit pretentious, but I wanted to do something new and different! SAP ERP products are great but not perfect. I spent over a decade performing ABAP and config work in order to mold SAP ERP systems into a shape so they do exactly what a business wants. Make no mistake, these years were very valuable for me and my backend expertise is going to come in very handy in my new job. But I wanted to get out and explore, see what’s beyond and discover pastures new.

Over the years I’ve brought a lot of help and value to businesses with my ABAPs and web apps, but it always entailed changes or enhancements within the ERP core system. Sometimes these changes were not easy to make, as end users wanted to keep their system as free of customisation as possible, fearing problems and endless regression tests further down the line.

Moreover, before ABAP OO came along, reusability of development components (DCs) was merely restricted to INCLUDEs and Function Modules. Thankfully this has all changed now. But let’s face it: adoption of ABAP OO based development principles is still not a reality in every SAP development team. Things have definitely improved, but it’s far from being fully adopted.

Enter Composition Environment, Netweaver Developer Studio, Composite Application Framework, Visual Composer, Guided Procedures, Enterprise Services Builder and all these other tools & repositories of a new service-oriented world that is Enterprise SOA. My new world. “The other side of the pond”, as I call it.

“Rest, Neo. The answers are coming.”, Morpheus (The Matrix)

However all these new tools can be quite daunting for a SAP Development Consultant who in the past usually spent most of his time using one single development workbench: SE80. In addition to new tooling and code syntax (Java), a CE development consultant also needs to understand the landscape far better than an ABAPer. It comes with the territory: if you want to build apps that link systems and leverage services then you surely have to know your backend from your Java stack from your Dev Studio. Simple as that.

If you’re an experienced ABAPer then you must expect to be out of your comfort zone (aka ABAP Development Workbench) once in a while. Books, TechEd videos, Tutorials, SAP help and helpful colleagues are hopefully at the ready to make the transition easier for you. Benefits you can reap from the learning process are more DC reusability, agile and flexible development, modern development tools and many, many more  (at least that’s what I hope for!). Imagine to cut down development time and deliver solutions to end users at a much faster pace than what you’re used to in SAP Land. Isn’t that worth the effort?

At this point I would also like to divert your attention to my CompriseIT colleague Tom Scaysbrook’s blog “Journey into SAP”, another great read in the CE arena and beyond.

So what are my observations so far?

  • I think that my background in SAP’s web app offerings and ALE/IDOC are a distinct advantage when it comes to understanding services, protocols, MVC paradigm, Object Orientation and parts of the new tooling. So if that’s your background, great.
  • Here’s the frustrating bit: most CE tutorials on SDN are out of date. Details in the tooling have changed in CE, disadvantage being that screenshots and descriptions have you got your head scratching more than once. It sometimes happens to me that I spend more time looking for a button or a tab than I actually need to complete the tutorial. CE consultant Thorsten Franz has also emphasized this on SDN some time back in 2008 in more detail.
  • diggin deeper: I was curious and had a look at the ABAP coding behind a web service for “sales order management” and was surprised. I guess my expectation was to see a lot of wrapped BAPI calls, but instead I found a lot of usage of the MV45A screen modules (even FCODEs). Very interesting to see how it was done though. Learning how to use BAdIs to enance web services is high on my agenda.
  • another perspective: another thing that I find fascinating is the Composite Application Framework. It is integrated into the NW Developer Studio and enables you to write your own CAF services but also define your own structures and data tables. Storage of data (or “persistence” as it is called) is all dealt with by the framework (which is nice!). The topic of “data storage in backend or CAF – pros and cons” will surely tempt me to a blog post in the future.

TO BE CONTINUED !