Tibco and Certificates

I've been messing around for the past two weeks with certificate chains, different certificate libraries, and keystores in Tibco with a third party provider. Man, what a mess. To come into a project where nothing is documented about which certs are used and have more than half a dozen of them (legacy) littered here there and everywhere around the module, along with another 7 or so new ones isn't happiness.
Interesting things I've learned through this experience are:

• It turns out that there are compatibility issues with .p12 certificates between java 1.4 and java 1.5. I had a pkcs12 certificate that I could read and sign fine in java 1.5, and yet java 1.4 could not find the alias in the same certificate at all. Apparently, there are a couple of ways around this issue - I only got one of them to work. One way is to convert the .p12 certificate into a .pem cert, and then convert it back to .p12 (all of this with openssl). The .p12 certificate is supposed to be readable after the conversion from .pem, but that didn't work for me. I got some kind of invalid tag error. What did work for me was to use openssl to convert the .p12 cert into a .pem cert and change my java 1.4 code to deal with the .pem file. To do this I had to use a couple of jars in the globus library. I remember something about a BouncyCastle class. :-) Also, here's a link I found helpful to discover what kind of certs you are actually dealing with.
• Getting those new external jars to work in Tibco Designer's Tester was a bit of a trick. First I added them in tibco's jre/1.4.2/lib/ext directory. That enabled me to compile the java code in the palette java item. But when I went to run the tester, it said I had code I needed to compile !?! I then I found I also had to add them into the path property in the tibco/designer/5.2/bin/designer.tra file so that Tibco's Tester would compile the code.
  
• Trying to load the module into production, I ran into two exceptions in the Tibco adminstrator tool. One was an OutOfMemoryError. This was resolved by doubling the java heap property found in the tibco/administrator/5.2/bin/tibcoadmin-.tra file, and also doubling the values for the min/max heap size for the module, found under the module itself in the administrator GUI. The second exception was a InputStream cut off IO error. This was because my module was too big. I was referencing java libraries that we already had referenced in a 'SharedResources' module we have. Getting rid of those drastically cut down the size of my module and it loaded fine after that.
  

Looking for a Pragmatic Development Process

Consider for a moment, if you will, the delicate balance between robust, thoroughly quality assured code and the amount of time it takes to put that code into production. I ran hard into the brick wall of 'development process' this week - an obstacle numerous people in our business had been complaining about, but I'm not sure how many people on the IT side of our organization understood.

My story went like this. We have some feedback from one of our applications that gets displayed in another in office application that was getting truncated. This truncated information was deemed valuable by the SME's and so a fix was requested. I looked into the fix, and it turned out to be a one character change in a cold fusion file. Getting this change implemented in production would not even require a server restart. After getting the changed entered in our bug ticket system and socializing the change with the appropriate stakeholders, it seems that our development process requires that I wait a full month before my change is actually implemented in production... and we're (supposedly) an Agile shop. What (on earth) is wrong with this picture?

This isn't the first time the organization has run into this issue. There have been other similar issues in the past - an email address needed to be changed. Could you please wait 2 weeks? If fact, this has turned into a major issue with upper level management (read execs), to the point that an entire system rewrite is being considered using a totally different technology with the main purpose being to cut in half (or more) the time it takes to get from requirements to production.

Personally, I do not think that the business and management is going to find their silver bullet in implementing a different technology for development. I think the problem lies in our development process being too rigid. 'We have one release a month - your changes go in that release and if you miss getting your change in by the code complete date, too bad'. Different technology will expose other problems. For example, a lack of appropriate hooks (or a complete absence thereof) for proper unit testing. Or, an inability to version and automate the configuration and deployment of the new technology stack.

Save a few million bucks on 'new technology' (it would really only be new to the company). Seems to me that it wouldn't be that difficult to set up a small, very part time team of a senior developer, a senior qa analyst, a senior ba, and an rm dude to assess these 'changes' that don't fit into agile's bug definition, but should be made in production quickly. If the change is deemed relatively innocuous by the team, put on your cowboy hat's and let's have five minutes of fun. Maybe that's going a bit too far - you want to capture the change in your build system. Communicate the risk to your client (very likely the same person or close to them) whose asking for the change, and then make them happy.

Please, don't make them wait a month for their change.