Outside

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.