Random Thoughts on Life

Saturday, November 17, 2012

Six most expensive words in business

Remember that the six most expensive words in business are: “We’ve always done it that way.” – Catherine DeVry

Saturday, June 30, 2012

That explains some things

I have always been puzzled by the poisonous atmosphere between the Development and Support departments at the company. An example of this is that for almost 2 years we have been working to institute consistent companywide software configuration management procedures and policies. This process has been stalled for over a year trying to get the Support department to implement them. The latest is that certain of their internal process that the “absolutely needed to retain” after their initial review over a year ago, and then became “optional”, have now become “these must be turned off before we can go live. If they are still on we won’t implement.” They formally informed us of this latest change this week, with a must implement date of the end of the week, and if it is not in place they won’t go live next month. After talking with the Stray Cat about a seemingly unrelated delay tactic by another department, the Stray Cat spouted off that yea when he was supporting the Development department he would tell them ok, fine, you won’t go live. Then he would “give them trouble” someplace else. Now I understand why the other departments pull this last minute “change it or else” business, because in the past it worked for them, in that it was a way that they could employ to put off anything they didn’t want to do. I don’t know what “trouble” the Stray Cat would give them, but for sure it is why we get such a poor attitude these days whenever we try and work with other departments on process improvements. Just another rodent that needs to be cleaned up, except this one is decayed, smelly, and will be with us for a long while.

Tuesday, March 13, 2012

Ok, so you really don't understand . . .

I had a conversation this morning with one of the new managers here. We are at the starting parts of implementing rollout of java based programs to our clients. We (I) found a minor issue 6 weeks back involving testing on our client systems. After 2 weeks of high pressure implementation issues he came to me this morning with a suggestion. His suggestion for working around this is to remove part of our java implementation and replace it with something else, as a way to work around the issues. It took me a while, but I finally have come to the conclusion that he really doesn’t understand the business environment we are working in, nor the issues we have had with this rollout.

From the business side, our company takes a very conservative approach to rolling out software updates to the clients, we allow them to install the new version of the software in parallel with the old version, with the new version accessing separate data files, allowing the clients to test the new version of the software without impacting current operations. The change he wants to make, in order to simplify the issues we have been dealing with, would cause the installation of the new version for testing to change the version of java being used on the production version. Now the change is probably benign, but it would still need to be tested, and the subtleties of running 2 different versions of java concurrently in production is something we could not validate in-house.

From the technical side, the issues we are dealing with have nothing to do with the code he wants to remove. They have to deal with running 2 different versions of java (one in test and one in production) and the code he wants to replace deals with how we perform communication from our legacy to java languages. (We chose to use an approach that requires some JNI code be integrated into our Java programs.) Replace the communications mechanism, and we still have the exact same issue of selecting the correct version of java to run.

Finally, the reason this has been so high pressured is that although I found the issue 6 weeks ago, his group sat on it for 4 weeks and did nothing to resolve it, until we were right up against the code submission deadline. The ability to install for test without affecting the production environment will always be a tricky issue. The ability to switch the version of java being run while doing this was going to require some thought and careful implementation, which is what I stated 6 weeks ago, and was ignored. The fact that we have had pressure about this is due to the 4 week delay in getting started and the fact that the person assigned to do this is not competent.

Overall, a very disappointing conversation.

Sunday, February 19, 2012

Sometimes you know they don't know what they are talking about

I got into an interesting exchange with one of our new developers this week. I was reviewing his korn shell code and noted that the method he used to split a string into two parts had a high overhead. (He was using awk instead of the korn shell built-in.) His response back was that he test out both methods using the 'time' command, and since both of his test times returned a time of 0.00, his method didn't have 'noticeable overhead'. This is when I knew this person simply doesn't know what he is doing or talking about. Both of his tests (his way and my way) were below the detection threshold of the 'time' command (10 milliseconds) so no reasonable information could be inferred from his results. (Taking the looping up 100 fold showed that my method had a 10 to 1 advantage in both clock time and CPU usage, took half the lines of code, and is more maintainable by other developers in our group because of the language.)

Sunday, December 11, 2011

Rube Goldberg Programming

So I was peer reviewing some code to create a BASE64 string from binary input (in PL1 where we can't just use someone's library.) This code takes a array of bytes to convert, and for each 3 bytes creates a 4 character BASE64 representation. The conversion of the 3 bytes is an impressive Rube Goldberg bit of coding. It first takes each input byte and converts it into an array of binary 1's and 0's. It then takes the binary array and converts it into a character array of 1's and 0's, while breaking the 3 bytes into a 4 sets of 6 1's and 0's. It takes each of the 4 character arrays and converts them into a character Hexadecimal representation. It then converts each of the Hexadecimal representations into a single BASE64 character. The conversion from BASE64 back to binary went through the same steps in reverse.

The conversion of the 3 bytes into 4 BASE64 characters can be done in a single loop. You overlay the 3 bytes with an array of 24 bits. Then for each of output character, you loop over the bits the character is going to represent, building the BASE64 value. You then convert the value into the BASE64 character. This is about 10 lines of code to do the encode and another 10 for the decode. This person took over 100 to do the encoding and another 100 for the decoding.

Gaaaaaaaaa!

Saturday, December 03, 2011

You really are already retired...

I had an interesting conversation the other night with the stray cat. On May 21st 2014 he turns 59 1/2 and will "consider" retiring "depending on the situation." I have news for you, you have already retired in place.

Another part of the conversation dealt with a situation we are having with one part of our system. We (very badly) support a remote duplication of our financial system for the purpose of failover in case the primary fails. We have numerous problems with this system, and 18 months ago there was a series of planning meetings to determine what areas we would work to improve it. I had pushed for enhancing the ability to stop and restart the system at known data points, increasing its flexibility and providing better recovery to network issues. The support people insisted this was not necessary, and we should switch the data transport over to a system know as NFS. My contention was that the current system was faulting out because of a bad network, and switching to NFS was not going to solve the underlying problem. The support people stated they had an example of a client running both the existing TCP and an NFS data mount they put in place, and the TCP solution faulted out their NFS based backup they kept on working. In the end we went with changing over to use a new NFS based solution. After 18 months of development, testing, and deployment, (over 1200 hours in total effort) the results are in. Indeed the NFS based solution stays up and running when there are network issues, however it quietly corrupts the data without reporting any issues.

What does this have to do with the stray cat? When we were discussing the issue, he thought that the NFS was the proper solution, because from an application level it was the easiest to implement. My thought is that it does not matter how 'easy' it is to implement, if the transport ends up corrupting the data it is worthless. My other thought is that we are now worse off in that with the TCP solution, the clients knew there was a problem because when it failed it announced the fact with an email and/or page. Now, the data is corrupted, and we don't know about it until we need it. He also brought up another issue with the software, not realizing that I had fixed it over 2 years ago. This is why I consider him retired in place, retired people bore you with stories about things that happened in the past, regardless of how applicable they are to today.

Tuesday, August 30, 2011

The moment when you know it is a disaster . . .

Today I had one of those moments, when you realize management made a decision, and it is going to be a disaster. My department has been working on software for our 2012 (next years) application release. As part of that, we decided that now was the time to shift to Java 1.6 and require it for the 2012 release. Our company holds the hands of our clients, providing a single point to purchase both our application and the hardware to run it on, along with supplying them updates of IBM's AIX operating system. We added Java 1.6 to the AIX updates 2 years ago, and with this years application release, were going to require that the client either be on the first release with Java 1.6 or acquire an 'unlock' from us to install the application update. The plan was we were going to track the clients requiring the unlock, so our support group would know which clients to push to update their system before next years application release, when it will be required to run the application. Well today, in a "Internal Release" document (that had 3 factual errors, and was in the client's hands within 30 minutes) it was stated that we will not be requiring the unlock after all. I found out today that this decision was made 2 weeks ago, when the head of support stated that it was going to "cost too much overhead" to implement the unlock process. My director was in the room, but neither myself, nor the head of the System development team were. Both of us are the major stake holders in rolling out Java 1.6, and neither of us were informed of the decision to scrap the unlock process. After I got done pulling the 2 week old knife out of my back (thats is why it has been hurting) I realized that we are now invariable headed for a disaster. Our projects are running full speed ahead, requiring Java 1.6 to be available on all client systems. I have this dread that we are going to get to March or April of next year and support will be, "sorry, we can't roll out the AIX update to all of the clients in time because it will require too much work." At that point, I am going to be asked to (again) pull the company's bacon out of the fire. At this point, I don't know what I am going to do, but it is going to be interesting.