Code of coding 3: Die, hard(coding)!

Development is an important phase of implementation of a highly-customizable ERP system, such as Microsoft Dynamics NAV, and that’s why I put a lot of emphasis on development, specifically on coding part of it. I’ve tried to cover a few do’s and don’ts of coding, but so far I’ve left one of my favorite clay pigeons out: hardcoding.

If you want me to define hardcoding, I’d probably put it something like this: hardcoding is the ugliest possible form of laziness, incompetence, ignorance, indifference, carelessness, or any combination of the five, which in short-term makes my toenails curl up, and long-term leads to poor and unmaintainable systems and unhappy customers.

Officially, definition of hardcoding would probably go somewhat like this: hardcoding is a practice of embedding settings into code.

There are two basic types of hardcoding: hardcoded output, and hardcoded input. Let’s investigate both.

Hardcoded output is when code or UI design in charge of displaying text, does so from the direct entry, instead from a central repository of texts. From perspective of Microsoft Dynamics NAV, typical example of hardcoded output is when UI elements and output messages are unaware of the system built-in capability to handle multiple languages simultaneously. A simple example would go like this:

ERROR('Dokument morate lansirati prije knjiženja.');

There are three basic problems with this line of code. For starters, I bet my kidneys that, unless you are from Croatia, you probably don’t have a clue what it means. A premise of a multi-language environment is that it should enable users to work efficiently regardless of their spoken language. The system should take care of user’s language of choice and automatically translate any output to that language. Well, the system can’t do it if a programmer does something like in the example above. The system doesn’t just know how to translate Croatian into English, or any other language for that matter. There is a mechanism which allows it to do so, and that simple mechanism wasn’t employed in this case.

Many a time I heard programmers complain that the system isn’t going to be used by anyone not speaking Croatian (or any other single language used for hardcoded texts) anyway, and that employing multi-language features would be waste of time and effort, so what the hell, why not simply hardcode the output text message? Because of the fact that the company may hire a foreigner, may be audited by a foreign auditor, may grow outside the national borders, and suddenly there is a need to have the true multi-lingual system. In any of these cases translation of the system will be somewhere at the experience level of Spanish inquisition. But regardless of multi-language feature this approach stinks anyway. Read on.

The second reason why the line above sucks is that it creates a very unmaintainable code in many ways. For example, your code grows (and code usually does), and there is another situation in which you need to display the same message. So you just go and copy/paste, big deal. Then you do it third time, then fourth… Then you end up with four different messages, which are really one. Then you decide to change the message, and change it once, forgetting about other three places. Or at best you need to do a search/replace. Which again wastes time, and might introduce error or inconsistency.

Third reason I will explain after I translate this error to English:

ERROR('The document must be released before posting.');

Now, does this stink, or does this stink? There are much better ways of achieving this functionality (such as TESTFIELD), instead of this one, which is both hardcoding and writing non-standard code. I’ve just made a note in my to-do list, to rant about non-standard coding techniques in the future, but for now, let’s stay tuned to hardcoding topic. It is hardcoding because it overrides the standard behavior which is consistent throughout the system, and replaces it with a fixed behavior which will stand out like a burger in deep space in case a future version of the system modifies the standard way how checking of field-level preconditions works. If anything has a potential to confuse and frustrate end-users, an inconsistent user interface does. Microsoft Dynamics NAV has an as-consistent-as-it-gets user interface, which makes for happy users by default, and “solutions” such as this one are on their best way to introduce unhappiness.

At this, I rest my case for today, this took me much more than I expected, so I’ll serve it in digestible chunks. My next post is going to be about hardcoded input, and it is something which is really bad, but not a bit less common than hardcoded output. See you later!