Skip to Content

What they think we do

It’s common knowledge, isn’t it? – Brilliant programmers solve complex problems by producing complicated code that is incomprehensible to mere mortals. Normal programmers could never take over that code and maintain it. Only a genius code wizard or, better, a group of the best programmers with PhDs and long track records could inherit a program from a brilliant programmer. You can also look at it conversely: The more complicated a program is, the more it indicates the brilliance of the person who created this Byzantine piece of work.

What we really do

All this is of course complete rubbish and nothing could be farther from the truth. The most important part of what we as programmers do is analysis: We break a complicated problem down into several very simple ones. Better yet, if we do this very smartly, all of the complexity vanishes into thin air. The second, equally important part of our work is synthesis, during which we take the pieces and build a new structure out of them. If we do this very smartly, we don’t even get a lot of different puzzle pieces that solve individual aspects of the problem, but an economic, intuitive and coherent basic structure that everybody can understand immediately and explain to their grandma or boss.

A challenge that doesn’t look like one

So in my opinion, a great programmer will tackle and solve problems that are too complicated and challenging for most colleagues, but she will normally drive out the complexity and create simple, intuitive and easily maintainable solutions that do not need to be maintained by a brilliant programmer. If you think you’re really good, here’s a test: Hand over your programs to the newbie for maintenance. If this works really well, and if an inexperienced colleague can incorporate change requests into your program while preserving the original architecture, then in my book you’ve passed – because poor programmers code programs that requires a team of geniuses to maintain, but great programmers can will their code to the new guy.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Matthew Harding
    If the not so great programmer doesn’t know Object-Oriented…then to that programmer it’s more like Arthur Clark’s famous quote…”Any sufficiently advanced technology is indistinguable from magic”.

    Luckily before departing, we can now point these people at Thomas Jung’s posts on learning OO to get them a head start (see!

    BTW – Whole heartedly agree with you!

    1. Tobias Trapp
      Well, I think Thorsten wrote about software design and not about ABAP OO vs. classical ABAP.

      But let’s discuss that topic: Classical ABAP has a lesser syntactical complexity but it has far more pitfalls that are now forbidden in ABAP OO. So from my experience ABAP OO is superior to classical ABAP. If you don’t agree with me you should test yourself with a list of bugs I published in my blog: My list of favourite ABAP bugs

      Best Regards

      1. Markus Theilen
        Hi everybody!

        After using OO(A|D) for many years and ABAP OO for even more years in production, for me there is no way back to “classic” ABAP. Luckily for me, I could start with ABAP OO from day one. The best part of this was, that I could transfer my knowledge of OO from other languages to ABAP with minimal “customization”. This is, what really should strike everybody: Learning to use OO wiseley in one language empowers you to get on the train in any other OO language. Getting started in another language is just about learning the different taste of syntactic sugar around the key parts of OO.

        The analysis and synthesis parts of Thorsten’s post in most of the times feels so much more natural in OO compared to procedural programming that I only fall back to the classic flavour of ABAP for the almost simplest test reports you can imagine. 🙂

        The good thing is that nowadays every newcomer from university come with good knowledge about OO, mostly Java. From my experience, these guys will have to learn a great bunch of new things (software architecture, design patterns, why on earth are there no good courses about design patterns at university ?!?), but they have very good ground to stand upon.

        Greetings, Markus

  2. John Soden
    I agree in theory although there are always trade offs – in my opinion reusablility (abstraction) should always win over readability

    also – I’m not going to try explaining SAP standard code to my grandma, does that make SAP developers sub standard?

  3. Steve Oldner
    I’ve just started writing more ABAP OO (or is that ABAPOO?) and agree it is more complex.  That being said, it is my responsiblitly as the senior to code in a fashion where the juniors can follow the program logic and be able to make changes when needed.  They might not be able to understand the problem, but they can understand the parts.

    Understanding the problem and breaking it into understandable parts is the ‘genius’ at my shop.

    Great article!   

  4. Abraham Bukit
    I have several experience where I came to new client and some change request required me to change their old programs. I can identify the quality of the previous developer by how easy it is for me to understand their code.
    However, i found myself often in a situation where i can understand the program logic but have no clue on why the previous programmer wrote that logic.
    I strongly believe a great developer must always put necessary comment in their program to allow others to understand the reason behind the logic. Of course, the best option will be to provide proper technical documentation for the program.
  5. Uwe Schieferstein
    Dear Thorsten

    I disagree with you: “Hand over your programs to the newbie for maintenance.” is not just a test but it’s the ultimate test.

    And this kind of quality has nothing to do whether the coding is classical or OO-ABAP (even though I prefer OO-ABAP).

    One major aspect (at least for me) of software quality which facilitates such a handover are naming conventions. Looking at the coding samples available on SDN it seems hardly anybody pays attention to that.

    Once it happened to me that I had to maintain a customer program developed by somebody else. Trying to understand and analyze the coding based on the rational naming conventions I learnt in the first consulting company I worked for I physically got a headache. The original developer was brilliant – according to your definition.


    1. Thorsten Franz Post author
      Hi Uwe,
      Why do you think this developer would fall into my definition of brilliant? Did you mean the ironic definition at the beginning of my blog?
      What I’m trying to say in this little article is that the best programmers write the most easily understood programs, so maintaining a program written by someone who is a good programmer in my book should not lead to a headache.
      I share your opinion that naming conventions are important for transparency. The help you see the smaller software modularization more clearly (I’m in a method – what is a parameter, what is a local variable, what is an attribute of the class or object? What is a reference, a structure, etc?) as well as see the larger structures (Which package, application, software layer, software component, type of development object, etc. does this belong to?).
      Personally I like SAP’s ABAP naming conventions and established style quite well because they work for me: They enable me to read the code fluently and see the larger software structures, framework architectures, etc. very quickly.
      To sum it up, I think there are two aspects of a software that make it easy to maintain for others:
      1) First of all, the structure of the software can be inherently simple. This is a matter of analysis and design as described in the blog: Did the designer manage to reduce an apparent complex domain to a much simpler model that actually works and covers the domain’s phenomena well in the same way a simple formula in physics might explain and model a host of different real-world phenomena.
      2) Secondly, the software communicates its own structure by means of being more or less explicit, adhering to naming conventions, containing comments, meaningful names for classes, methods, variables, etc.
      I didn’t cover the second aspect in my blog but I think it’s equally important.
      Best regards,
  6. Paul Hardy
    In regard to naming conventions, I would agree that this is important. You may ask why the vast majority of “customer” companies do not adhere to naming conventions. I suggest it may be because that when you look at standard SAP code there appears to be no sort of naming convention whatsoever. A gentlemen from Australia called Matt Harding once tried to establish a worldwide naming convention for ABAP code that would even be adopted by SAP itself. Sadly, this got nowhere.
    I have been on two SAP training courses in ABAP, admittedly quite a few years ago, and in both cases the instructor said “we do not advise you on naming conventions, do whatever you want”.

Leave a Reply