Reply to post: Re: Cue fireworks and a victory parade

Sysadmin cracked military PC’s security by reading the manual

Stevie Silver badge

Re: Cue fireworks and a victory parade

Whereas I needed a change to a stored procedure which no-one claimed to own, in order to make it read a directory from the database instead of a hard-coded variable value >8o(

I tried the obvious code difference but nothing worked. So I sent out a more general call for help and was told to report to one team leader, who now claimed the code and snottily told me he would take care of it and not to touch his stuff and so on and so forth.

He erased my code, then called me upstairs again to show off the changes he had made. I took a look and told him it wouldn't work. He asked why I thought that. I answered that he had simply re-written the code I had put in - that didn't work. (I at least had the excuse that I am not a PL/SQL programmer; he was hired as an expert PL/SQL developer).

I went away and noodled around for a bit and more by luck than judgement hit upon the way this tech was supposed to be coded. I wrote a test proc and ran it with all sorts of fail scenarios to make sure I had m'facts straight.

I sent back my findings by email. Mr Expert then said I should make the change in the proc. I did so. He then insisted I move it over to the test system (despite my telling him I had already tested the file access code) and "test it". This involved creating a dataset from live data and about two hours hard work. When I was done, he snottily grabbed back his code and took the credit.

Fast-forward a couple of years. There's a problem with the process this proc drives. Devs are speaking pompously to DBAs about "what are they going to do to upload the data". I am out sick that day, but get a phone call. I tell the DBAs to answer "Nothing. We do not upload this data. It is processed by code owned by Mr Expert. We have been expressly forbidden to touch this code or modify its working in any way. We stand ready to assist the developers in any way we can in the solution they devise to their vexing problem."

Apparently the look on Mr Expert's face was classic as his make-it-someone-else's-problem strategem belly-flopped. And I laughed all the way through the four day remediation that resulted in Mr Expert losing much sleep. Fuggim.

About six months after that we did a DataGurad switchover and another proc started bleating about directory access. It was clear another hard-coded variable value was to blame. I was called to task for changing the directory name, but pointed out that in fact that had not happened, and that I had placed a soft link as a temporary fix and professional courtesy on the old primary system to make everyone's buggy procs work the last time we had switched over, and that I had said that this was asking for trouble and that it was eventually bound to cause the exact problem we were seeing.

I then went on to add that I would of course add the same soft link as a professional courtesy in the interest of not impacting the production schedule, but that the proc code needed to be fixed as a priority so it wouldn't happen again at the next switchover in six month's time or when we needed to redefine the file system under the directory object for SA reasons.

I then tossed the ball even further into their court by saying that the code needed was already deployed by another dev group, and that Mr Expert had a proc he could show them that would explain how it all should work and that "his code" would be a robust way forward.

No credit for me, but everyone went away, if not happy, secure in the knowledge that the problem could be fixed with minimal effort and I got to avoid another "you own the code for the next four hours" ploy and no need to keep track of stupid soft links to cover dev arses.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019