Stop Hard-Coding Before It Stops You

April 14, 2004 Kevin Vandever

It drives me nuts. How can it be that month-end reports don’t run correctly all of sudden? These same programs run every month, and no one has modified them in years. Now the numbers are all wrong, and the you-know-what has rolled downhill, all the way from the CFO’s desk, and has landed smack dab in the earpiece of my telephone. Ouch! Yuk!

Sound familiar? Of course it does. It’s probably happened to all of you out there. It happened to me as recently as last week.

These crashes and errors don’t just affect month-end processes. They can happen to any OS/400 application that has run smoothly for many years, without modification. One morning you wake up to find that your seemingly stable application software is not so stable. What causes this to happen?

You are probably thinking that it must be data-related, that software just doesn’t stop working properly without a programmer’s help. Well, that may be the case. Perhaps the program has worked all these years but was not tested to handle a specific type or structure of data that is now being introduced. You are correct–that happens a lot. And although it may result in the same frustration on the part of the CFO, that particular issue can be traced to a lack of foresight in design or poor testing. These are both frustrating to deal with but are much easier to understand than the what that I see happening all the time, when an application suddenly produces incorrect results.

Your crack team of application developers digs in to figure out what went wrong. They might first look to see if a recent change was made to the code. Nope, nothing was changed since the internally described file description (I-spec) was last changed back in the 1940s. Okay, maybe not that long ago, but nothing in the last five years. Your team then decides that the data must be bad, so they take time to create DDS for those darned internally described definitions, to copy the data into those newly created files, so that the data can be analyzed, and to write queries to check the data. Your situation may differ somewhat, because, hopefully, you are dealing with a better database design and programs that are more current, but maybe not. Anyway, after hours of analysis and head scratching, along with the occasional re-running of the application in question, just in case it has miraculously fixed itself since last night, your team then either gives up and passes it to someone else (yes, this actually happens), or figures that they had better look at the code, even if it hasn’t changed.

Once they’re in the code, your team will come across clues that aren’t so obvious at first, but in the end, will spoon feed the problem to them like a mother spoon feeds her toddler. These clues are the hard-coded business rules or data that reside in all applications. With careful analysis of this hard-coding, you will undoubtedly link applications that you never thought were linked, and maybe shouldn’t be linked. You will also uncover solutions to unsolved problems that have been reported back to the users as intermittent issues, but what really translates into IT not knowing how to solve that problem up until now.

Indirectly, this is a data issue, but not the type of data issue I mentioned earlier, where unforeseen data enters a program and creates havoc. This issue is caused because permanent data exists as part of your application. Hard-coded status codes, compile time tables that contain exchange rates, geographic location codes, cost centers–anything that duplicates data in your production data files is part of this problem. This is bad form and should be stopped immediately and avoided in the future. This is what happened in my situation. It turned out that specific codes were changed in a master file, yet the original codes existed in a compile time array in a program that runs at month’s end. This program was written long ago, before the master file was created, and was never converted to use the master file. This stuff happens, but it sure is hard to find sometimes. The safe thing is not to use compile time arrays to house data that can be checked or accessed in database files. This could lead to wonderful debate on the pros and cons of compile time arrays, and it may be fodder for a future article, but for now I will ask you to stop hard-coding business data into your programs.

I don’t even care if you think the data will never change, such as the fifty, two-byte state codes. The data might change. Who knows, we might get another state, split California into two states, or give up a state that we don’t like that much. Besides, why hard-code this information into every program that needs it, when you could use one of many, more dynamic methods?

The days of slamming all of our business logic inside our programming logic is over, or should be over. We have so many methods at our disposal to allow us to stop this madness and still create more flexible, bullet-proof applications, without sacrificing design, efficiency, or sanity. Our application software should be much simpler. We should use the database, not our programs, to select, sort, and validate our data. We talk about how over-worked we are in IT. We talk about the long hours, the stress, and the lack of recognition. Well, hard-coding data into your programs is directly related to all those issues. If we took the time to better design and simplify our applications, we would work less or not get so stressed out. We would also get more recognition. Or we would at least hear nothing. That’s right, we would be like referees or umpires in the major sporting events. When you don’t hear anything from them, or you forget they are there, that means that they are doing a good job.

By stopping the habit of hard-coding data into our applications, we can go a long way toward reducing the hours and stress we endure, while also removing the attention that we attract to ourselves. If every time you pound yourself on the thumb with a hammer, you feel pain, you usually try to avoid pounding yourself with the hammer, right? Well, the same should hold true with hard-coding. Stop pounding your IT department with hard coding, because it hurts.