Click here to monitor SSC

Simple-Talk columnist

We Don’t Need Another Hero

Published 22 May 2009 10:53 am
Stan, the SQL Hero, had a meteoric career at the large Financial Services Company where I worked. He burned red-hot when he hit the upper atmosphere of the company, and caused a brief flash before hitting the ground.

Stan ‘the man’ was a Sybase and SQL Server expert. Over a quiet glass of wine in the Clubhouse, my friend Mick, who was the Development Manager, proudly told me of his luck in recruiting such an exceptional individual. The agency had put it pretty strong. This guy had certificates beginning with ‘M’ where ordinary mortals didn’t sprout certificates. Mick was cock-a-hoop. I was loath to dampen his sunny mood, but he was a chum and I felt it only fair to warn him.

“You’re playing with fire, Mick; you just want a guy who can quietly slot into the team and work diligently within it to bring his knowledge to it without causing disruptions. You don’t need a hotshot, but someone who is socially aware, with solid and wide-ranging competence. “

It was no use: Mick’s mind was made up. Here, he thought, was someone who could cause a radical shake-up in the department and, to use his macho term ‘kick ass’.

I was working as a technical architect, plotting out the high-level strategy for the migration of a number of systems, so I was slightly out-of-touch with the everyday life of IT Development. However, I couldn’t help noticing, after a while, that Mick had gone quiet on the subject of Stan ‘the man’. One day, however, the Production IT Manager popped to my office, looking a bit flustered. He’d become alarmed by a financial reporting system which had been submitted by Development for release and deployment. Basically, The Production Manager had to decide whether to accept responsibility for maintaining this application as a production system. “Ah, Phil; you know a bit about SQL Server don’t you?”.

I gave him the Stare of Death, but his psychic force-fields were in place. “I’ve dabbled a bit.” I replied.

“Cop a look at this”, he said, slapping a listing of the database build-script on the desk in front of me. Hmm. Odd. Was that a One True Lookup Table? Aiee! Did that stored procedure really execute the contents of a column called ‘executable’? I glanced, with rising panic, through the listing. It was the work of intellectual brilliance. Had the investigators of the Roswell Incident found a listing, it might have looked a bit like this. In order to service a request for a financial report, this application created screeds of dynamic SQL based on a number of different conditions, and then did a CUBE which then could be queried on a number of different rotations. One would be able to see what was executed via a trace but not from the listing. It was the first time I’d seen the SQL Code actually stored in a database table.

“This is clever stuff, and I don’t pretend to understand it all”. Uncharacteristically, I tried to break the bad news gently, but he flinched on the word ‘clever’.

‘Phil, if you can’t, how the hell can I maintain it with the team I’ve got?’ His voice rose in pitch as panic set in.

‘Well, there are three database developers in the team that wrote it. Couldn’t we just get one of them to train your people up, and write up sufficient documentation to assist your group?’

He gave me a quizzical look. ‘The only guy who understands this stuff is the guy that wrote it; Stan ‘The Man’. The other two members of the team are on the point of going off sick with the effort of repressing their homicidal urges against Stan. Stan’s evidently much too busy rubbing the noses of the developers in their ‘Newbie’ database mistakes to have the time to provide adequate Database documentation. He’s cutting a swathe through the Dev Databases finding all sorts of ‘worst practices’ and recounting them in amusing terms to anyone who’ll listen.”

“Well, I’d refuse to allow it into production until it meets the full requirements for documentation and support as laid out in the corporate Computer Manual pp. 135:159”

“Oooh! Is that fair? Come on, Phil, harsh.”

I gave him the Clint Eastwood look. “Sometimes, it must be attack in overwhelming force.”

Next time I bumped into Mick, the head of IT development, he definitely looked a bit part-worn. Either the stress of losing a round of golf had got to him or else Stan had already finished his meteoric trajectory in the dirt. I didn’t need to say anything, but merely signaled to the barman to come up with a sympathetic Jack Daniels.

By the second tot, Mick poured out his woes. Stan was a SQL rock star, but had not kept a close eye on the audience reaction. The average IT team is a delicate lattice of sensibilities, emotions, affiliations and resentments. Give me the complexity of a corporate data model long before the interplay of human interactions within a development team. Stan had solved countless database issues, but had left a trail of interpersonal wreckage and humiliation in his wake. Before long, realizing that he had become indispensible, and that his new, and essential, reporting database could not be maintained without his continuing expertise, he had just asked for his salary to be doubled.

“Mick”, I said, “you know what I was taught when I first became an IT Manager? Rule one, if one of your IT staff becomes indispensible, then you should dispense with him immediately. Heroes are the stuff of fantasy. Armies are best staffed by people who get on with the job, inspire their team, and keep their heads down. It is teams that deliver good business applications, not individuals.”

He downed the rest of the glass and waved for another. “So, it is time to refuse his request for a pay-rise, and transfer him to the Compliance team?” We shook our heads sadly. Stan was about to take the Big Sleep.

I was happily dosing off in front of a network diagram in the strategy office a fortnight later, musing over the impermanence of IT careers, when the IT director sidled into the room shiftily.

”Phil? Are you well, Good good good. Yes Splendid. Nice to hear that, Phil.” Pause. “Ah! To get to the point, Stan ‘The Man’ has handed in his notice, and I’ve allowed him to go without working his notice. We’re in a bit of a pickle though. “ I missed the alarm I should have felt.

“The fact is, Phil, that the Business is pretty aerated about the possibility that the new Financial Reporting System might not be delivered on time. Mick says the remaining members Dev Database team can’t fix it. It is beyond them. The Production DBAs say you’re the only one who could turn it around, so I’m seconding you temporarily to the Dev group to fix it.”

Theatrically, he dropped the horrid build script listing on my desk. It fluttered open on a page that had a SQL statement with twelve joins in it. I closed my eyes: it was going to be a long month.

6 Responses to “We Don’t Need Another Hero”

  1. Rockstar says:

    Phil,

    You may well define him as a ‘rock star’, but to me he was a bad hire no matter what he would be called. You have brought to light all the traits that hiring managers should be weary of bringing on board to their teams.

    However, not every subject matter expert (SME) or every ‘rock star’ is cut from the same mold. Some of us can actually function well in teams and play nice with others.

    SQLRockstar

  2. Philip Kelley says:

    When he dropped the printout on your desk, isn’t that the point where you should have asked them to double your salary? (And then, as they stare aghast, you chuckle and said “no, 25% should be sufficient”.)

  3. Phil Factor says:

    Philip,
    The thought certainly crossed my mind, but after a couple of nanoseconds, it dawned on me that this strategy hadn’t exactly enhanced the health-quotient of the career of the Stan the Man. There is always a time to smile sweetly and agree to be a temporary SQL Hero myself, and this, I think, was one of those times! Besides which, I owed the IT director a couple of favors. Why? Well, that’s another story!

  4. Duke_Ganote says:

    Pretty horrific, but I’ve seen the opposite too: teams too “comfortable” with parsing flat files to want to use an integration tool like SSIS to pull data directly from another database, too “comfortable” with cursors to use SQL, etc. etc.
    http://www.simple-talk.com/sql/t-sql-programming/rbar–row-by-agonizing-row/

    And yes, I’ve read your chapter on the Acronym Playpen. Speaking of which chapter, how did the Rockstar’s implementation differ from your “workflow interpreter” that executed scripts? You wrote “Everyone was fearful of going near the interpreter because it smacked of Computer Science: anathema
    to the jobbing programmer.”

  5. Duke_Ganote says:

    Interesting reading…”Is the Most Productive Employee Really the Most Productive?”
    http://jrothman.com/blog/mpd/2009/05/is-the-most-productive-employee-really-the-most-productive.html

  6. Phil Factor says:

    Sorry to be so late answering your question about the Acronym Playpen. The workflow interpreter didn’t just pop out of my head, but was a consensus decision by the design team, which also ‘I checked with the high-priests of the IT Department’, to get round the impossible constraints placed on the development project. It also isn’t hard to do and I used dijkstra’s shunting-yard algorithm http://en.wikipedia.org/wiki/Shunting_yard_algorithm to get around the problems that VB then had with recursion. The developers were told of this design feature when they were recruited. The last time I enquired, the interpreter still underpins the system, ten or more years later.

    The sort of hero I rail about here makes himself indispensible by ensuring that his contribution is a personal one rather than a team one. The real professional approach is much harder, which is to disseminate enough knowledge within the team or department to allow one’s contribution and ideas to be adopted, and developed by others. Thanks to the trick of the Acronym Playpen, we got over the emotional resistance to what was the correct, consensus-based, design decision.

Leave a Reply