Versioning Means Nothing When You Sit on Top Of The Ivory Tower

At the Product Job, I didn’t just travel but I also did a lot of technical support while I was in the office. That wasn’t so bad, but it was a bit liked a whack-a-mole. You see , the Lead would sit on his ivory tower, er, office, and tweak things and the commit the code. And when we would “cut the code” (i.e put on floppies to install in our lab or to send to a client) we could see that things were changed. This is all fine and good but the version within the application didn’t change and there were no build numbers. So, literally, we had 2 machines with 1.1 installed in our lab that acted differently, because they were running different code.

When we would show the Lead this lack of consistency, he would deny he did anything. A few hours later, he would tell someone to come into his office and he would show them that it worked for him. “Install it again!” So we did — and what do you know, there was changes. And so of course a re-install worked

I’m sure I or one of my co-workers got burned by this while on a client’s site and I decided enough was enough. I was learning a fancy scripting language. All our machines in our testing lab were NFS mounted so I could squirrel this code away somewhere the the Lead would look for it. I installed the language on one of the test machines and started writing. I was lucky the that build server was also the NFS server and it shared the build files. I wrote a script that would run once an hour and detect changes and, if there were any, it would email me. I waited until I got my first email and then I went to the lab, where the Lead was having his usual argument with our QA person.

"Hey Lead, what did you change?"

"I didn’t change anything."

"Oh I got this in an email." And showed him my printed out email. He looked sheepish and QA was interested in how that email came to be. Soon our whole support and QA group got the email.

And soon we got subversions in our builds.