STOP filling your Custom ABAP Code with Business hard coding

[SergioFerrari]

Updated: you may also want to check out subsequent blog Get rid of Business Hard Code from your custom ABAP Code 

Introduction

IMHO, "Business hard coding" is one of the worst and underestimated ABAP programming practice.

Here just an intro to the topic while in a subsequent blog you’ll find useful stuff to get rid of it.

I always considered hard coding really a bad practice but, only recently, I’ve got the real evidence of how much it is used. It happened during the Custom ABAP Code review services we're delivering at TechedgeGroup.

Hard coding requires the program's source code to be adjusted any time the context changes and in business, it happens quite often.

With “Business hard coding” I'm referring to the practice of hard coding strings (literals) corresponding to codes (IDs) related to Organizational Units, Document Types and even Master Data and that is one of the worst kind of hard coding.

Some examples are Company Codes, Purchase Organizations, Sales Organizations and Accounting document types.

Instead, I would not be too much worried about "Technical hard coding", the practice of hard coding strings corresponding to technical stuff like dictionary objects and output formats (e.g. tables, fields, colors, icons).

In add, hard coded strings returned to end-users as part of messages, titles and columns headers belong to a different bad practice related to the internationalization (i18n) topic.

A couple of examples

For a better comprehension, a couple of examples follow.

In the next picture, method ADDRESS_CONTROLS_IN contains two hard coded strings used to differentiate message severity. The first is related to Company Code and the second to Purchasing Group. Here hard code is even used generically to check everything starting with IN*.

I would guess that India has a specific business requirement.

In the next picture, method MANDATORY_VATCODE contains multiple hard coded strings to differentiate message severity. The first is related to Country Code, then to Company Code and my favorite one verifies that the GL Account beginning with ‘004’.

  I would guess that Poland has a specific business requirement to be combined with a type of GL Accounts.

Why real life SAP systems are full of Business hard code?

I'm sure, most of developers will justify the use of Business hard coding explaining they have been in hurry and the time to create new customizing tables or BRF+ rule was missing. In part they are right, I know that customers (internal or external) demand often for very fast results and developers operate accordingly.

I also have evidence that a large number of developers consider Business hard coding the only way to go and let's say even a good practice.

Discussing with them, to demonstrate they are wrong, I’m used to say that in hundreds of millions of lines of standard SAP code there is no occurrence of "Business hard coding" (to be honest with very few exceptions like country codes and partner functions).

Why Business hard coding is so bad?

Probably the hard-coder (the author) will be proud to show his/her skills solving issues and adjusting the business hard code only he/she is aware of (lock-in). Even if at customizing level everything is correct and identical to a working scenario, different behaviors of a transaction/report are often due to business hard code.

Time saved during the development phase will lead to much additional effort during the next roll-out or at next Merge&Split when business requirements will change.

Where Business hard coding is acceptable?

In the reality, Business hard coding is an acceptable practice in:

• Throw away objects
• Short living projects

Maybe it can also be useful to classify above exceptions assigning the objects to specific throw away Packages (Development Classes) similar to $TMP but transportable to production.

Speaking about serious and productive Custom ABAP Code, I'm sure you want to get rid of Business hard coding as soon as possible.

Best alternatives

In modern SAP systems, there are lot of alternatives to Business hard coding for example like:

• BRFplus Business Rules
• custom Customizing Tables
• Filters in BAdis as described in the must to read blog Best Practice for a SAP ECC Consolidation project: filter dependent BAdI to organize the user-exits ...
• in FICO maybe also using SETS
• in MM SD maybe also via Conditions
• Report PARAMETERs and SELECT-OPTIONs
• Parameters managed in table TVARV

Conclusions

I'm going to share very soon also the way we use at TechedgeGroup to perform a full scan of your Custom ABAP Code looking for Business hard coding and I’m also very interested to hear your experiences and ideas.

[former_member182371]

Hi,

this subject is becoming a classic.

It´s been repeated quite a "few" times.

And always the one to blame is the developer.

In some projects you find functional specifications litterally specifying that you must hardcode certain values.

Everybody feels entitled to code or pseudo-code.

We developers are trapped between pseudo-coders on one side and abap gurus on the other side.

If these say you do not need have initiative (just follow the specifications) the others blame you for bad practices.

Sometimes and specially now (economic crisis and huge unemployment) we cannot allow ourselves to be the "smart" guy.

So yes keep complaining (cause you´re right) but bear in mind that most of us are not respected

gurus and cannot allow ourselves to have an argument with our boss.

Wish life was easier but it is not.

Instead of the title:

STOP filling your Custom ABAP Code with Business hard coding

i propose the following:

STOP following functional specifications implying Custom ABAP Code with Business hard coding, just call an abap guru to protect you.

With all this i mean that this article should be addressed mainly to those writing functional specifications.

I´m fed up with those despising developers (for unkown reasons) and i´d love to claim some respect for us.

No we are not silly. I repeat it again: we developers are not silly.

Best regards.

[TudorRiscutia]

Hello Sergio,

Very nice blog!

A really good solution for these situations is SAP NW Decision Service Management. It is in fact based on the BRFplus framework, but centralizes and extends the functionality.

Yet in some cases, I find it alright to use hard-coded business rules, as some of them won't really change in our lifetime :smile:

Tudor

[manwell77t]

Not only the worst way to develop but also the most difficult behavior to get rid off!

[SergioFerrari]

Hi Pablo,

I know and I understand your comments. Indeed I anticipated your opinion saying "In part they are right,...".

The title could be better but it seems working fine since you started a good discussion that was the intention of the blog post.

It would be great if you can share with the functional guys this post to evaluate together if economically speaking is better to hard code or to be more flexible.

  I'll be happy to get your feedback also in the next blog I'm posting here in days. It will provide the way to automatically discover most of Business hard code. I hope that will really help.

  Best Regards,

Sergio

[SergioFerrari]

Thanks Tudor,

I like looking into the standard software and there I can see flexibility implemented more or less completely via customizing tables but yes, SAP NW DSM is for sure the most advanced solution !

  Now I'm wondering about examples of Business hard code that won't change? Can you share a couple of them?

Sergio

[former_member182371]

Hi Sergio,

thanks for understanding.

I was just implying that behind a single line of code there is more than meets the eye.

Regrettably it seems i wont be able to share anything with the functional guys for a long time.

In my two previous projects i had arguments (besides personal differences) about functional specifications and this has cost me nine months of unemployment so far.

So next time (if there is any) that someone tells me to hardcode whatever is needed i will probably close my eyes and i´ll try to be more "flexible".

Best regards.

[maximilian_schaufler]

Sorry to hear about your colleague's/employer's lack of understanding.

What I came to think of reading your comment was:

at least "hard-code" it as a class constant, might not be perfect, but both sides could live with it.

[maximilian_schaufler]

Totally agree.

Unless you have someone at your side to teach and guide you in your early developer years, it's a bad habit hard to shake off.

[maximilian_schaufler]

Great input, Sergio.

Looking forward to hearing more from you on this topic, especially your way to clean up existing code.

[Former Member]

Hi Sergio,

hard-coding is in deed a common bad practice.

Fortunately it's actually pretty easy to detect by static code analysis tools.

As an additional awareness-motivator: Our current research shows that 99% of all customer installations (survey of 190 systems) are affected.

An affected system usually has 600+ occurences of hard-coded values.

However, we are not only monitoring BUKRS in our analysis.

We also check for hard-coded values in

- User names

- syst variables (e.g. host, mandt, ...)

- Passwords

- RFC destinations

- E-Maill and IP addresses

- etc, etc

Cheers,

Andreas

[SergioFerrari]

Thanks for the valuable contribution.

99% is always an interesting number that means something and I'm wondering to know about the 1% that is not hard coding business values. Or it is a champion or it just started with SAP and we have to wait few days to reach 100%.

Best Regards,

Sergio

[Jelena]

Well, sometimes we just think it's a "short lived project" but it somehow turns into a huge thing later. On the other end of spectrum are the cases when we invest in a good design, go through all the hassle of generating maintenance screen for a Z table, etc. just to find all your effort scratched in 6 months. If only we had a crystal ball! :smile:

I really wish there was just a single "one size fits all", convenient and easy to use solution to this provided by SAP. So far from all the alternatives listed the custom table is probably the best bet (it is not module-specific and rather flexible), but even with that I've seen some consultants struggle. At first they need to be reminded to use it but then they start using it when it's not even needed (e.g. in a report where we can just add a parameter). What is wrong with the humanity, ugh...

P.S. Is there some problem with adding a checkbox to the country customization screen? SAP is just as guilty as everybody else on this.

[Jelena]

Andreas Wiegenstein wrote:

- RFC destinations

In our system ABAP Help on CALL FUNCTION... DESTINATION... doesn't have any code examples. Google search finds this Help article as a first hit and it only has the hardcoded values as examples. A beginner who is already sufficiently confused by the whole RFC business might not be in a position to dig further. How difficult would it be to add an example like in this SCN post to the Help article? We need better education on best practices IMHO.

[SergioFerrari]

Wow, your writing style is really awesome !

You, a "techno-functional" (I like it) leader and top contributor of the community, are confirming that the practice is sometime acceptable and that SAP itself is guilty for missing flexibility. That's interesting too !

About SAP, I would be happy enough if they will loudly define Business hard coding as a bad coding practice to be avoided as much as possible in productive ABAP objects. With that kind of bold statement I bet authors of Functional Specs will avoid writing instructions clearly not aligned with SAP best practices (check out previous comments by pablo.casamayor ).

I think SAP never spent time to communicate that business hard coding is a bad practice because they cannot even believe someone is adopting that pattern. As said before, SAP delivers hundreds of millions of lines of codes without any occurrence of it.

On my side, I'm going to provide a convenient way to discover all occurrences of the bad practice and I'm happy that, TechedgeGroup, the company I work for and SAP partner, is becoming a BusinessHardCode-free company.

[Former Member]

Hi Sergio,

just to "bug" you on this: Virtual Forge is already a BusinessHardCode-free company for at least a year. :razz:

Cheers,

Andreas

[SergioFerrari]

Andreas, you did not "bug" me.

I know there is always someone better and I'm happy to get confirmation from a such famous and respected firm.

[ChristianGünter]

Hi,

basically you're right, but there are some principles to consider.

In XP there's the YAGNI principle You aren't gonna need it - Wikipedia, the free encyclopedia. I think it's important to consider this in the ABAP world, too. If you in the first place put all you're business values and other type codes in customizing tables, BRF+ functions or whatever, you'll end up with lots of objects never used a second time. This happens especially when business people discover that the delivered functionality isn't what they want. So, as a rule thumb, i would say hard code type codes at first time is tolerated, but if you have to change the code for the second time, to add a new type code for example, it's time to apply the mentioned tools.

P.s. There's also another famous saying by Donald Knuth: premature optimization is the root of all evil - Premature Optimization

Just my 2 cents.

Christian

[Former Member]

Hi Christian,

sorry, but I definitely disagree with the YAGNI principle in this case.

If you hard-code organizational information in your business applications and your organization changes and you don't know *all* the hard-coded occurrences and fix them, you are in trouble.

"hard code type codes at first time is tolerated, but if you have to change the code for the second time, ... it's time to apply the mentioned tools" to me sounds somewhat like saying "writing insecure code the first time is tolerated, but if you get hacked, it's time to apply better practices" ...

Cheers,

Andreas

[ChristianGünter]

Hi Andreas,

thanks for your reply.

Maybe i formulated my thoughts incorrectly and i have to readjust.

My key point is that you first have to ensure to meet the business requirements and then you have to make your application customizable through z-tables, BRF+ etc. and replace the type codes. If you've choosen the wrong algorithm which is discovered during testing and you've already done a lot of the mentioned configuration management this effort is lost.

Christian

[Former Member]

I don't want to have to open up a program to change hard-code values. Whenever I get told 'We will never change that value' then alarm bells ring.

'We don't want people to see to see the records based on 'XYZ' so we only ever want 'ABC' selected'. Sorry but SAP/ABAP has a pretty comprehensive authorisation system in place and you should filter at that level. Checking the users authority at code level is easy.

'We don't have time/Its costs too much' : When one of the finance guys tells you he doesn't seem to be getting records for (say) a cost-centre and on running his own query found several months of records he should have seen, then its likely already costing much more.

At worse you can put an input-dialog on the screen with default value that the user can change or add-to as required. They can even store that as a variant if needed.

If you don't want the users changing those things then keep the otherwise hard-coded values in a separate table along with a maintenance-dialog that only the supervisor can change....Plenty of other solutions based on that.

Changing a single value select for a different single value in the code is straightforward. Adding multiple new values and it can start start to get messy. Pull the values from an external table and the code is ready for single, multiple and zero selection.

The exception here being those legacy data-loads for a go-live. They get tested a thousand times and usually used once in anger. The programmer can usually quote that code like a poem during that time.

[Former Member]

Hi Christian,

I see your point.

But your approach also produces lost effort.

If you code, then test, then code better, you need to (fully) test again. That makes the initial test a lost effort, too.

So the question is, what is more expensive for a company: coding things the right way early on (and risking re-design) or testing multiple times?

Cheers,

Andreas

[ChristianGünter]

Yes, you're right.

or testing multiple times?

In an ideal world we would have a solid test suite which we can run automatically to avoid regression errors. But in reality this is seldom the case.

Christian

[Jelena]

Sergio, I'm not really calling hardcoding "acceptable", but realistically it's difficult to combat unless you have "zero tolerance policy". Even this blog already provides loopholes - it talks about "business hardcoding" and mentions exceptions like country codes. I'm not that old but even in my life time some countries ceased to exist and some new ones appeared. General Motors and 3M are older than Croatia and Bosch outlived the USSR. :smile: So where do we draw the line exactly and based on what criteria?

By the same measure SAP is far from being hard-coding free. Sure, we can call something "business" hard-coding free, but it reminds me of those big "fat free" labels you can see on some candies in the US - it's true but doesn't make the candy any better for you.

[SergioFerrari]

Yes, I consider country codes exactly as company codes and plants, sorry if it was not clear before. They should not hard coded.

I discovered lot of IF BURKS = 'DE01' OR 'IT01' OR 'FR01' ... to identify those countries part of the European union. At the nice is that at times new countries are added to the IF. New CR, new Regression Test and so on so forth ...

About Business" hard-coding free , I'm with you but communication often requires short and direct messages like in the Advertising business.

[Jelena]

Hi Pablo! It's my understanding that in some cultures there are strong traditions where a person in senior position (or just older) has ultimate authority and power just because of their seniority. This can be highly ineffective in the professional setting, but obviously we all have to play the cards we've been dealt.

From my experience, the developers can easily fall into what I call "communication trap". Let's face it, usually we're not very good with people (why would someone become a programmer if they wanted to deal with people? :smile: ) and might have trouble conveying our best intentions. If we say "your pseudo-code is awesome and I see an opportunity to elevate it to the super-duper level by replacing hard-coding, would you object to that?" it's more likely we get an agreement. (And if not - well, it's their loss, at least we tried.)

Also if you have the development standard in place that forbid hardcoding, that should trump the functional spec. And if you have a development team lead above you then just defer the whole conversation to them and bring out the popcorn to enjoy the fine spectacle of the office politics. :smile:

[paul_gerrits2]

First of all, thanks for this blog, all developers and functional team member should read this and these comments :smile:

Personally I don’t think any values should be hardcoded...BAD PRACTICE in most cases, (unless one time programs/objects/load programs etc). And never beleive when the business or function folks say, well that will never change: Never say Never.... 

I also don’t like using TVARV as in IMHO as it is overused and misused, which makes it a nightmare to maintain for the functional users. It also has some limitations and the values cannot be transported (There are few instances in which the values would change from Dev, QA, Prod, but not many)

My preference is to have the values as parameters on the screen if you can, you can save the variants. If this is not possible for business reasons, or you don’t trust the users to fill them in properly or select the correct variant, then we do the following.

What we have started doing is having a generic class coded for each functional area, and having a generic table that can support putting in your variable values) (eg, ZFI_CONFIG) - (replacement for TVARV so to speak). Then if you have a program that needs a hard coded variable, you simply call the class method to retrieve...you can add new methods in the class if needed for complexity reasons and also define your constants in it.

Advantages:

1. Table can be transportable, you could have two generic tables, one transportable and one not.
2. The maintenance of the config table can be put in SPRO, with documentation on how to use it and what it contains, updated for each variable you add. Makes it easier for functional to maintain and there for furture reference right in SPRO.
3. You have one class and one set of methods used to return any variable that you need in your program. If something needs to change in these class methods or your need to add new methods etc, there is only one place you need to change.
4. Methods to retrieve should be static, so just as easy to call to get the value as it is to hard code the value as you dont need to instantiate them. 

That said, there are some instances of course that you will need custom tables to hold them, if your requirement cannot fit into the generic mold, but I have not found too many instances that the above will not handle.

If you run into trouble with the folks you’re dealing with because they insist on hardcoding, then you need to explain the consequences of having hard coding should the values change and the amount of rework and regression testing that would have to happen vrs simply changing a table entry. Once a generic class is developed to do the retrieve, then it will take no more development time than using hard coded values.

Just my .02c

[jdloranger]

Paul,

this sounds like a very interesting solution.  I was not familiar with the TVARV possibility to begin with and your solution sounds even better.  Do you have any links that would provide more detail on this?  Or would you consider posting a blog on the topic?

Thanks,

Justin

[Jelena]

Paul, this is definitely a great solution. We use a similar approach with a custom table (just one table works for us) and a function (which could also be a method, of course). This table is used in the user exits, routines, etc. programs that can't have parameters. And I've seen the same at other SAP customers. This makes me even more curious why it was not delivered as some standard SAP tool.

E.g. if SAP added an empty table (or two tables, as you've mentioned - transportable and not) that the customers could use, then every ABAPer would know where to go for their hardcoding replacement needs. Or at minimum those could be used as a "best practice" template for how things need to be done. It's possible that SAP thought we'd look at their config tables as such template, but then the message did not convey very clearly, it seems.

Thank you.

[alespad]

interesting blog as always Sergio!

my worst experience about the topic:some years ago I saw jn Sales Order user exit MV45AFZZ a CASE statement with the system name!

when 'DEV ..when 'TST when 'PRD'!!!

I'm not a big fan of TVARV...probably the quick way is Z-table with a static class method to retrieve values..or a good old SET.

curious about SAP NetWeaver Decision Service Management 1.0

[Former Member]

We use the exact same solution of Z-table to maintain hard coding for all objects (programs, FMs, classes etc). This Z-table has generic fields that can contain any value as per the requirement and some fields as identifiers.

This solution is working absolutely perfect so far.

[jrg_wulf]

Hi Christian,

YAGNI is a reality, but the opposite is too. All of a sudden, you find yourself in the situation to readjust some single shot coding, for something barely different from the original use.

So i decided some time ago (about when i decided to abandon procedural coding for the most) to use a hybrid solution:

i use a functional method, returning the literal value in the first place.

Now, whenever the need for adjustment occurs, the only thing i have to do, is adjust the method, advancing from literal to case to custom table, feature, BRF+ or whatever seems to meet the needs best.

Thus, the additional effort is, even considering YAGNI, not to be mentioned, whilst still maintainingall the flexibility for future adaption to complex logic.

Jörg

[former_member609416]

In addition to the complexity of not hard coding values, some business users simply do not want it as they realize what it means.  "Oh, you mean I have to remember to change the settings now?  I prefer asking you to do it.  Is that not your job?"  Or at least I see that expression on their face as I actively move away from their request of hard coding values.  This problem occurs in a lot of different areas of various programming disciplines that serve users.  I noticed that hard code request from business users is pretty common in my area.  If you charge per hour, I suppose its not a bad thing as they'll likely come back and pay you again to change the hard code.  But if your salaried, it gets annoying as its not challenging, is frowned upon across the discipline, wastes time, and increases the skill gap as a programmer is required to make changes.