A colleague created an enhancement, and it was put in UAT (User Acceptance Testing) Environment yesterday, and he then left for vacation for a week – oh, and it’s scheduled to go into production this Sunday. He asked me to “test” it since the end users didn’t really know “how” to test it according to him. Anyway, I tested it this morning, and the enhancement causes an email notification to be generated. Well, it seems, there were two typos in the generated email.
I spoke to the “change coordinator” and told them, it would be really embarressing to put this in, and have everyone see these types in the emails they would be getting from our applicaiton. They spoke to my team lead, and he said “it’s ok, but we WON’T be putting in an unscheduled emergency CR to fix the types on Monday, we’ll just fix them with a regular CR in 7 days”. So, I have a couple of issues with this: first, he wouild agree to put in the bad code knowing it was “bad” (Yes, does the code function and doesn’t have bugs, yes, but the typos are embarressing). Secondly, you would think, he would come over and ask me to investigate whether we (“I”) could create a fix for the typos, to go into prod at the same time as my collegues enhancement. But, he never asked me for my assistance – not sure if he even thought of it.
Anyway, I figured out, later, it wasn’t in the code, but it was just a configuration data record, which means it could be changed by a production support admin, and the enhancement code didn’t have to change (which would have required a new UAT testing cycle, and the delay of it going into prod).
So, then, the issue becomes, do I change the config data record to fix the typos (in UAT and PROD), knowing I really shouldn’t be changing data in either of those environments – the production support person/admin is the only person who should have the ability to do this. Again, no one asked for my help. Well, I was a rebel at Unisys, and after discussing this with a different colleague, I took the initiative and fixed the configuraiton data record. Well see if I get any flack over doing this (in prod). What I did, really was a thing that a person could be “terminated” for – due to Sarbanes/Oxley auditing considerations, separation of programmer duties from production support, etc. It was a lot eaiser at Unisys, when we didn’t have this type of separation – the programmers/developers did everything, moved code into production, changed data in production, etc. We certainly got a lot more done at Unisys, this way, but it also could have been the cause of much trouble, if the person doing that type of thing wasn’t competent, and screwed something up, by deleting data by accident.
Oh, this reminds me, I have to blog about what happened last summer within our DEV and SIT (system integration testing) ENVs, and the database where the development code is stored, when we upgraded the ITSM7 app to the next support level. I bet you all can’t wait to hear all about it! Let’s just say, the DEV and SIT DBs were deleted/removed by accident, and we didn’t have any recent backups!
