Tool Upgrade

We upgraded almost all our development tools in this latest change cycle. This is nice for developers. We like to use recent versions of the toolsets. This is a nightmare for developers. When you change multiple tools at once, it is hard to identify which change was the cause for any given bug.

Here are the tools we changed during this pass. Moved up to the Oracle 11g client. Upgraded to Microsoft Visual Studio 2008. Jumped up to Installshield version 18. Also grabbed a recent copy of the Objective Toolkit. Ouch. Everything is changing.

The first pain was that the new Installshield was so much newer than our ancient copy, we had to write the install scripts from scratch. That was a quick weekend hack that just did not work. I spent a lot of time reverse engineering the pieces of the install that were missing from our rewrite.

Next we had some pain from Visual Studio. Installing the runtimes was not as simple as dropping some DLLs in our application directory. Turns out we either need to run the Microsoft installer, or use the support supplied from Installshield. Growing pains really hurt.

The third party tool upgrade required some work. There was some disturbia initially when the developers could not quickly figure out how to build the third party components. We had to do some due diligence to figure out how to build the darn thing. Once that was solved, we quickly figured out how to use the components and deploy the minimal set of third party runtimes.

I am just happy that I only spent about a month or so dealing with all the upgrade problems. Another developer took over and spent an additional month or two working through the problems.

Hard Coded

I got called to an emergency meeting this week. The configuration data in our production system was not correct. There were some missing values. That called all the data into question. There were a bunch of questions about some values of suspect nature.

I waited for a while. The guilty parties did not speak up. So I piped up that development did not have time to be thorough with some late development. I knew because I got called in at the last minute to help the developer figure out what the module was doing.

So the developer hard coded all values this time around. It appears he also left a remnant of the configuration data in the database. However this data was unused. Therefore the values in the config table did not matter. A manager was upset that he was not in the loop about these decisions.

Finally the developer who did the dirty work did pipe up. He said that all his decisions were peer reviewed by managers. Everything was written out and reviewed. I guess that really means the manager approved something he did not comprehend. Next time pay attention man.

I was tasked with putting together a plan to get us out of this mess. First step was to get the needed production configuration values out there and verified. Next we will need the developer to spend the time to use config parameters to drive the module. We will need a lot of such parameters. Then we will need to document all this stuff.

I like to be conservative. So I propsed we implement this is the next major release. And when we do roll this thing out, I will grab all the managers and explain the ramifications of everything we are doing. Luckily it is easier to explain that we are doing things the right way finally.