Supportable Coding in Data Warehousing

Not all code is created equally. So how can we get to a point where we believe the code solution presented is acceptable for use?

Code Snippet

The process of expressing an idea through code has too many factors involved to use any real scientific judgement. The very fact that we all use different benchmarks to decide what we do and don’t like about a piece of code is itself a fluid expression of where the code reader is at.

Review code you wrote 10 years ago and it becomes clear that your pride and joy (back then) probably invokes a different emotion now because you see the world differently. This means that the same idea would now be expressed using different code.

So what should be the goal when it comes to supportable coding in data warehousing? Over the years a few guiding principles have become clear:

  • Keep it simple;
  • Modularise the blocks of code;
  • Comments that tell the business story.

These are high level coding principles aimed at improving the coders interaction with the code. They are a supplement to be used along side the real world needs for coding standards, security, performance, minimum functionality, configurability, etc.

Keep it Simple

Keep it simple because the next person to maintain the code after you will probably know less. While this sounds arrogant, it’s not. This is a reflection of the career path that most of us experience; we start out supporting existing solutions, learning as we go and eventually we learn enough to design and create them ourselves. In the beginning, we knew less.

Keep it simple for maximum supportability and ensure the overall data warehouse solution will live for as long as possible. Quite a few DataModeling solutions have expired within less than a few years because the coding was considered too complex to support, despite that fact that the business rules really were that complicated.

In the end these solutions die a quicker death because the original business process and business requirements were not ultimately supportable. The complicated code was just the expression of this much deeper, original business issue.

Modularise the Code

Modularising the code into small discrete objectives is worth the time and effort. When you support someone else’s code that has been logically separated into simplified goals you get two advantages.

The code is easier to adjust when a bug is found because the regression testing is simplified.

It is easier to grasp the overall flow of the program because blocks of code (the modularised sections) honour a simplified story of what it is doing.

Even the most complicated business goals can be broken down into small and manageable blocks of code. The ability to read the code and relate it back to a piece of the business process becomes a lot easier.

Comments Tell a Business Story

Comments should read like you would talk to a fellow developer or business person, never 100% technical. By all means, mention technical objects and strategies but remember that the comment itself is targeted at a human, not the program compiler. Write your comments from the perspective of identifying “What the next block of code should be doing”. The block of code itself will “Tell the story of how it is done”.

When you review your code and realise that the story has changed between blocks of code; then it is time to add another comment and let the person reading your code know what it is that this new block of code it trying to achieve.

“comment the code to tell a story”

Sometimes a single line of code will require its own comment. At other times a single comment will be enough to identify what the next 15 lines of code should be doing.

For Example: The “SYST-UZEIT in Formula Builder” solution can be understood using two completely different perspectives. Go through it once reading only the comments. Go through it again reading only the code. Each read through is a completely different reality that all depends upon your level of coding experience.

The code should not be considered complete and ready for use until the comments reflect an accurate story of what the code should be doing.

What coding principles do I consider important?