Hard Coding Production Applications

| Saturday, February 28, 2009

I have never understood why anyone would hard-code a single line of code in a production environment. The implications are so large that one would think twice about doing it right?

I'm guilty of doing this very early-on in my programming career as a very junior programmer. I created a web reference in a .net 1.1 application and forgot to mark it as 'Dynamic". Everything was fine and dandy until the reference needed to be changed during a deploy. The scrambling that went on during that time was insane. That was my first and last experience with hard-coding a production environment.

Don't get me wrong; I still hard-code certain things. For example, if I'm slapping together a quick demo, or creating a very specific unit test, then sure I will hard code. Doing this in production is sloppy and very dangerous. You really tie your hands in terms of agility and you increase the cost of change in the future.

I recently worked on a major engineering effort that required replication from a legacy database to sql server. I worked with Crash data modeling and was able to get it functional in no time at all. The time consuming effort was replicating the legacy model, a flat file approach, into our normalized sql model. Once that was done, the next major effort was balancing the two systems (this is an ongoing effort). The interesting thing about replicating is that I was forced into hard-coding but this is not a production client-facing application.

I've been done with the replication part of the project for some time and have moved on to other things, like reporting. I have delivered reports to QA and considered the project done as far as the specific schedule tasks were concerned. The legacy system continues to provide all reporting and drives all UI until we start pushing more and more reports through QA.

The programmer that I worked with is an Application Lead Developer with over 20 + years experience working with this legacy programming language. His responsibility was to write programs that send his data through to my replication programs. We worked well together, other than small disagreements on the data model and who has the better database. It's all just banter really.

This programmer approached me on Friday and asked me if I was ready for the next update (the client was loading a lot of data into our system very soon). I was curious what he meant when he asked if I was ready. Did I need to prepare for something that I was unaware of? Were there new requirements that needed to be implemented? I was confused about his question. The data model had been written and functional and was always ready for new data. So I asked him to elaborate on his question. He asked if I was ready because I was responsible for all the reporting for this new load of data. I thought to myself, I'm not responsible for any reporting, only writing reports, the business is responsible for the reporting. I started to understand what he was getting at. I told him, that I did not think the reporting would come out of the new system because the two reports I hade done were in QA and we still did not balance (something he is aware of and has a few tasks to complete so that we can balance). He seemed a little annoyed at my response and told me that this meant he had some work to do if he was going to provide the reporting. I asked him why he had work to do, it was just reporting, the same reports we have always provided. He said that he had hard-coded his reports specifically for the prior year and that some more programming needed to be done so that we could report on 2009 data. It was at that moment that I realized why he asked me the original question. His entire programming world is a giant hard-coded mess of spaghetti code. He was shocked that I was not prepared because he assumed that I needed to program my reports to handle the new data for the new year. I, in return, was horrified at the though of him hard-coding anything these reports. I'm sure my programming buddy was someone who lost sleep during the Y2K thing...

This got me thinking. Would Crash be ok with this? Is he even aware that this programmer is going to be spending time hard-coding his programs so that they were compatible with 2009 data? I'm sure he will be aware of it after this post (I have a sinister laugh right now). When I think about the big picture here I wonder why such a senior programmer would do this. I'd like to think that he was under a serious time crunch but I don't think that is the case. I think it is a philosophical thing. I get the impression that he, and several other programmers on the legacy system, are accustomed to hard-coding all the time. That's just how they do it; it is innate in them. In fact, one friend of mine called it "job security".

Without disrespecting this programmer; I want to ask him to justify his decision to hard-code. I don't think he realized the cost involved in that decision. To him, it's just another day at the office. I doubt he gets the whole technical debt thing.

Powered by Qumana

0 comments:

Post a Comment

This blog has an advanced spam detections system. Send us spam and we will shoot a missile into your living room.