For the most part, I love maintenance programming. However there are some bad things that come with the territory. I hate getting those late night production support calls. Don't get me wrong. When my code crashes the system, I want somebody to call me up so I can fix it. However I hate being the go to guy who gets called regardless of the problem source.
This is why I read with great interest a set of tips for avoiding that late night call. One is to teach others. You got to make sure other people know why things are implemented a certain way. That way they are in deeper than just an understanding of the code. And they can take those late night calls instead of you. So noted.
Another global activity that can prevent the midnight calls is to keep fixing bugs until the system works. Too often we hurry up and patch something. Then we move on to other tasks like writing new software. The problem is that the simple band aid will eventually come off one day. Murphy's Law states that it will come off at the most inopportune time. For me that is 3:00am.
We have a lot of back end code that runs during a nightly process. Here is a criminal design methodology we use. We do not validate the input. Yes I know. That is a recipe for disaster. The problem is that this stuff needs to run quickly due to the volume. So we assume everything will be ok. In case you have not figured this out by now, nothing is ever ok. That's it for now. I have a lot more to say about this issue. Stay tuned for some more tips.
Package Access Mystery Solved - I have been playing around with the DBMS_CRYPTO package, trying to generate a lot of hashes. I want to study the distribution of hashes for different inpu...