Skip to Content

Software guidelines – Why are they rarely adhered?

Software Architecture has been one of the most ignored topics in IT world. There are in-numerable documents justifying the need to architect the software solution but somehow we seem to miss the train, every time. (There are exceptions but in general we miss the train).

Software guidelines are mainly documents, which provide the path to Nirvana i.e. steps to be followed to produce a quality product. SAP, has been advocating the usage of its guidelines for all its IT practices to be implemented. Invariably, we find IT practices implemented by teams based on their past experience and the MOST important ingredient – gut feeling. From the simplest of guidelines (coding standards) to the most complex practices (SAP NetWeaver implementation), there is a penchant against these guidelines. It is even more interesting when we find the deeper reasons for this behavior.  

During my planned travel to Germany, I received a document from the HR team detailing the accommodation rules in Germany. One section of the document was very interesting. The document provided detailed information on the garbage bags and their individual usage. Here is the part of document: 

– Paper and paper boxes – green/blue/grey can
– Residual waste – black can
– Biological waste – brown can
– Plastic, packages, tins, “Grüner Punkt”-products – yellow bag/can
– Glass – has to be brought to special glass containers and be       separated by the color of the glass
– Plastic Bottles – there is refund on most bottles, you will receive the money when you bring them back to the     shop\chain where you purchased them
– Glass Bottles – on some glass bottles (e. g. juice bottles)            there is refund

Coming from India, we were informed of the benefits of segregating the garbage but never had imagined of putting in the necessary effort to segregate the garbage. I discussed about it with my wife and she was more than happy to follow those rules. She was very appreciative of the efforts taken to safeguard nature. I was totally surprised to observe the ease with which this rule was accepted. When, I look into it deeply I found resonance of the same all around us. When, the rules are enforced with some penalty, the human mind somehow adjusts itself to follow it. But, when there is a semblance of lenience in the rules then human mind convinces us to not follow those rules.

To ensure that we stick to the best practices of the software implementation, there needs to be an intervention by the higher management. The guideline document will only educate the teams about the pros and cons of a particular process. To ensure that teams follow these guidelines, there should be few strategic rules imposed on the teams. The key is these decisions should be communicated within the organization as non-compromising.  

Example: Every custom development in SAP needs to be evaluated with respect to Web Dynpro ABAP and JAVA. The detailed evaluation document would be used to take the decision on the technology. Once the technology is decided, it needs to adhere to the coding, integration and implementation standards.  Now, you would have come across these statements in many documents but with not the desirable effect across the teams. But, if all the teams are required to follow these steps, then you will find more and more teams following this process of implementation. As you would see, the actual enforcer is not the team but the communication by the top management (Now, the developers have the right to blame their managers for not being strict about following the steps). 

In times when products are made simpler we still have guideline documents running into pages and pages filled with texts. Some are extremely exhaustive and in the end communicate too many points. So, the teams tend to miss the core point.  

To achieve the full benefits of these guidelines, we need to prepare more user-friendly documents. It is better to keep it simple to allow both technical and non-technical people to understand the document.  

As a responsible organization, it is not enough to have a vision but it is very important to communicate unequivocally the adherence to the guidelines to fulfill the vision and facilitate the implementation with simpler documents.

You must be Logged on to comment or reply to a post.
  • We have guidelines.  We also have code reviews.  We - the developers - have gotten together to try to put them together.  In places, I agree to disagree, and so don't follow that guideline.

    I try to have all the consultants that work here follow guidelines.  It works until the end of the project comes around.  And then WHAM brick wall in the blink of an eye.  No more following guidelines, and at times no more following good coding practices.   VERY FRUSTRATING.

    Next - seriously - how do you set up a contract to follow your guidelines.  Yes, we can and have done that.  But of course we don't put all the rules in the document.  There are things that are just good (and common) programming practices.  We have to assume a general knowledge of programming practices – or  that they can program.  Well their programs might test fine functionally.  BUT can / not always be horrible when I look at the code.  At the end of a project, if it doesn't cause performance problems,  I let it go through.  Thus we have programs that don't follow our guidelines.

    Even my own don't completely follow the guidelines.  They do for the most part.  But what did we both just say?  They are guidelines.  Meaning they give you a general way of doing something but it is a suggestion.

    Love blogs like this - making me think,


    • Dear Michelle,

      Thank you for your feedback.

      I concede to you, that in the end they are guidelines. They are not the be-all and end-all. So, some practical decisions needs to be taken to make things work. In my experience, this premise is used by most teams to ignore the guidelines completely.

      The Technical lead should take decision on what can be ignored and what needs to be adhered. Also, if they are expected to substantiate the concession then they will be more judicious about it.

      Example: Travel claims are a great example. Everyone know there is limit to claim. Most times we try to stick to limit. If we overshoot, the manager can decide when to approve the claim and whne to reject it.

      Thank you.

      Sharath M G
      Thank you.

      • Agreed. 

        We always do a code review.  The main guidelines about performance are always enforced.  The struggle is when consultants are asked to redo something like putting all the logic together in one subroutine.  Ahhhh!  My personal frustration.   So that isn't in our guidelines.  MVC - split out your logic.  Just good programming practices.   Copy and paste the same logic and don't use a subroutine.  Again not exactly spelled out in our code reviews.  We assume people know not to copy and paste the same code all over.  Designing classes that really can't be reused.  For example designing a class specific to your program instead of specific to the task.   Again it is assummed they know this.  (By the way I pointed that one out early on during our Blue Printing Meetings.  It was ignored)  Making a dynpro for Z table maintenance when the table is only going to be updated once a year.  Table generator anyone?  Writing a function module and Z table to retrieve sequential numbers.  Again I would assume that they would know to create a number range.   AHHHHHHHHHH!!!  Basic programming skills.  They go beyond guidelines.

        They don't know objects, and we are starting to require them.  That is in our standards.

        They answer I don't know how to use the classes for ALVs.  They say they can only use the function module.  That one really bothers me.  We have examples, and it is in our guidelines.  The list goes on and on...  My frustration is sometimes very high.  I did write about good and bad consultants.   And it's a struggle sometimes when there is a revolving door with contractors.

        The problem is inside people follow the guidelines and good programming standards.  We may not all be working with classes / methods but we are moving towards it. 

        The naming conventions are something we don't enforce.  (The one where I agreed to disagree.) 

        Will the consulting firm make us pay more for their consultants if we are requiring them to make fixes to their code?  Sometimes if it isn't completly spelled out in our guidelines.  Get real.  We can't put EVERYTHING into our guidelines.  Common good programming is expected.  And how to you write that into a contract?

        Then there is the end of the project code review.  Only the performance guidelines are checked.  If it is total junk - I make them redo it.  But sort of junk, that gets by.  So whose fault is that?  The systems fault / timelines and my fault.  We do not hold up code reviews if it will cause the project to run over, and it doesn't cause performance issues, short dumps, or the wrong functionality.   Early in a project, yes.  Late when the project is just at the deadline or late...  They slide.  It makes me wonder if we need them at all.  Of course they make things easier to maintain.  And my code comes back with changes too!

        Great blog!


  • In the dim distant past when I was responsible for ABAP work and we made use of contractors, the policy was for every contractor to be accountable to an internal employee (it helps if the ratio is not too high) The employee was responsible for educating the contractor on the software development guidelines and policies and was accountable for the quality of the code. The ABAP team lead was responsible for spot checks of code and the QA team would periodically participate in this exercise too. This explicit 'contract' between all the parties moves some way to making sure that people produce conforming code and documentation. The challenge as I see it, is sustaining a continuum of quality - no mean feat when your organization has a lot of resource churn and change velocity.

    A nice post by the author...remember keep sorting your trash....someone has to.

    • Dear Clinton,

      "The challenge as I see it, is sustaining a continuum of quality" - You have raised a very valid point. As a developer, it may be easy to advocate standards based developments. The scenario may be completely different when you are responsible for deliverables to customers. We need to constantly remind the need of quality.

      Thank you.


    • Yes, we try to do that too.  One of our internal resources paired with a consulting company.  But what happens when there is resistance?  When there is a time for making them fix the code.

      And... There is the fact that the contractors can change many times over.  There is the time difference.  Webex works well, but e-mail is harder to work with.  How about the consultants that don't speak your language well?  Or at all?  (I'm impressed when anyone can speak multiple languages, I can't)

      Or the person who asks the same question in a different way multiple times.

      Or the person whose code has the same problem over and over again.

      Yes, I agree talk with the project manager.  BUT that doesn't always resolve the issue.

      Sustaining a Continuum of quality.  What a great idea!  Sorting out our trash - we try to do it when we maintain a program, and then get asked by the project manager why we are taking so long.  Or just trying to maintain Trash code.  It takes longer.  Pay me now or pay me later.

      (By the way our old code stinks.  But if it works, we are not going back to fix it.)

      Love the response and the blog!


  • Cool blog indeed. As being one of the Best-Built Apps (BBA) guys (see I can only agree: of the two things: creating guidelines and enforcing guidelines the enforcing might be the much harder thing to do.

    With BBA we help our customers and partners on the create part and partially also on the enforcement. Some customers told me that they use BBA for negotiations with their contractors and since BBA are “official guidelines” from SAP they ask at least for a justification from their contractors why certain guidelines might not be followed.
    But “governance” of the development process, as we call it, is not an easy topic. I’d love to see more blogs like this one and maybe some discussions and Q&A in our BBA forum: Best-Built Applications . For customers/partners in the Americas you might also join the ASUG influence council about BBA and development governance and participate in our next council session at TechEd in Las Vegas.


    • Dear Jeorg,

      Thank you for your feedback. You and SAP have done some very good work with BBA. I have used some of the BBA guidelines in discussions with customers(at times in implementation, too 🙂 ).

      My activity is in SDN. It would be my pleasure to participate and contribute to the BBA community in ASUG. You can let me know, more on this council in ASUG.

      Thank you.

    • I have tried to keep up with BBA.  It's hard sometimes.  BUT that's a great idea have the consultants read that first.  I know I've been happy about it for a long time. 

      Just enforcing the guidelines is a struggle.  Hence me answering a lot of these responses.  Even though it wasn't my blog.  It's just one that has hit a spot within me that makes me want to be able to enforce guidelines at least 90% of the time.

      Thanks for the comment - I tend to forget we have the BBA.


  • What I see is the programmers who can get a program done fast and with the correct functionality get a pass on good programming techniques. They are the stars everyone wants on their projects because they buzz through the RICEF list. Who cares if their code is ugly, hard to follow, not commented, full of abandoned logic that is never hit, etc.? Well of course anyone who has to revisit that code later for changes cares, but not the project managers or the end users who just want it done fast and running right. Arrgh! We all talk the talk, but few walk the walk.
    • Dear David,

      I can truly feel the frustration. We can try our best to do our best in our tasks. The more we perfect our work, others will follow suit. The problem is it is easier to find the mistakes  in other's code but difficult to be judged by others. But, it is never too late to do quality work and be honest about our work.

      Thank you for the feedback.