Thursday, February 28, 2008



I talked about the Productivity Consultant we had here a couple of weeks ago, the one who looked at our broken processes for part of a morning and then left when her own tears of blood began to stain her shirt.

This week she has been back, but she brought help. All week I've been sitting next to a Technical Resource from her company. The guy is extremely good at what he does, technically. The place the whole company misses target is in the non-technical parts. They both ask questions but are uninterested in anything beyond the direct answers to these questions. Suggestions by my peers are ignored almost on principle, but I'm learning a lot about what a Productivity Consultant does.

Yesterday the technical guy asked why we could only do one thing at a time on a server and I told him that more than one thing on one of these old servers makes them grind to a halt in the best case. For our main build machine it can freak out and reboot resulting in a Disk Check at restart which takes over 24 hours to complete, not that we've ever let it complete.

A few hours later, he came back with the idea that this company needed to buy more servers, newer servers, with some parts covered by some form (any form) of warranty.

"Really?" was all the response I could muster. Of course they need new hardware here. Some of the production systems are still proud to be Y2K ready.

"Yes," he answered,"More and newer servers would let you do more builds."

"I know," I saw the communication error I had made,"When I said 'really' I wasn't doubting that your suggestion was a good one. My 'really' was just based in surprise that your first impulse was to throw hardware at the problem. If we didn't have six breaks to fix at a time, even the crappy old servers could probably handle it."

I didn't get the impression that many technical people ever balk at buying new equipment when he suggested it. Again, he was right. Our servers are for the most part unsupportable crap and disaster will strike at any moment. . . . But we can throw hardware at problems all day and our process will be as broken as ever.

"What do you see as the biggest problem then?" My window! Let me show you it!

"Look!" I pointed at the latest build request in my mail client,"This is what a build request looks like. There are no details unless you go the calendar entry and open the Word Doc, like this."

I started to open it, but it took a minute because of the 30 other build requests I had open at the time.

"Okay, here it is." Two glorious pages, mostly blank.

"We have the client name, right here," I pointed, "What build server hosts that working directory?"

"How would I know?" he seemed more wary, like it was a trick question or something.

"I'd look that up, cross reference with our repository information. There is none, so I'll start powering on machines until I find the right one and then turning off the incorrect ones as I go.

"Next, I create a new folder with the client name and today's date . . . Because that is all the information I have.

"I pull these issue numbers, 17555, 17658, 17241 and 15373 and do a search on this sub-folder of my Inbox for the check-in emails relating to them. I drag these emails into my new folder, except for 15373, which pre-dates the creation of my Inbox. I'll grab that data from the log on the repository server.

"I take these emails and copy the file locations into a text document, then go to the build servers and actually do my job.

"After this, I take my text document  and send it to someone named David and he adds these 'Release Notes' to the corporate Wiki site where no one ever sees it again.

"Later, the person that requested the build comes over to my desk to ask if a certain issue number was included and I reverse the steps to determine that. Then they ask for the purpose of the patch, which confuses me because if they don't know why did they request it?"

He was silent for a moment.

"That is a broad process issue," he explained,"A fundamental break-down of good business and technical process."

"Exactly." I thought we might be getting somewhere. Then . . .

"That is outside the scope of this project."

"Outside the scope? What the hell is in the scope? Adding servers we requested before I started here in November?"

"I think I can justify that purchase if you can document it."

I think I can justify stealing office supplies.

If there were any office supplies worth stealing.


Joe said...

Perhaps they've just watched Python's Dead Parrot sketch too many times?

"This server is no more. It has ceased to be! It's expired and gone to meet it's maker! It's a stiff! Bereft of life, it rests in peace! If you hadn't nailed it to the server rack it'd be pushing up the daisies! It's metabolic processes are now history! It's off the twig! It's kicked the bucket, it's shuffled off the digital coil, run down the curtain and joined the bleedin' choir invisibile!! THIS IS AN EX-SERVER".

Sorry ... I have too much time on my hands today ...

Jane said...

"My window! Let me show you it!"


PS My brother's work (bank software security) still uses COBOL.

Garrick said...

Joe- I've printed your comment and taped it to the front of the main build server. Let's see how long it takes people to notice.

Jane- COBOL is pretty bad. This company uses Objective C and YellowBox from about the same time as U2 was cool. Apple announced Objective C 2.0 in 2006, but that project seems to have died already.
The compiler won't run on anything more recent than Windows 2000, and even that is an ugly port of an Apple compiler.

jane said...

Are you saying that U2 is no longer cool!?

Garrick said...

I'm afraid it is true, Jane. Please see the next post for some evidence I've uncovered.