Life In SCM continued…

One of the things that always freaked me out about my new job was that I was automating it. I was preparing the development team to move to an automated process that would do 75% of my work. That left me wondering where I would go once the automation was complete. That is certainly never a good feeling to have, and it doesn’t help when your co-workers start asking you that same question.

I pressed on with the automation because it was something sorely needed for the development team and myself. Our code-base was growing, our projects were growing, and our development team grew.  Project managing our semiweekly and large monthly releases, while training developers, upgrading our web environment, and going to school full time took its toll on me. 10-12hr work days were the norm, and sometimes even went beyond that. Manually cross checking our code-base and reviewing check ins, revision number changes, deployments to delta, dev, and beta platforms was just a chore. Though the automation was the light at the end of the tunnel.

What is this automation I speak of? It was a true CM System with change management controls in place. This tool replaced one major document I used that tracked all changes, approvers, and testers…sorta. See this release management document kept track of all bug fixes and enhancements. It tracked the reason we were making changes to the code-base as well as tracking the files and revisions used for that particular change. With this new system I no longer had to do this manually. The developers tied their change to a request and it automatically tracked it through automated reports. This automated report was updated several times a day and only took minutes to create while my manually created code analysis reports took 3-4hrs per release and I updated it weekly. This system also enforced code reviews, code security, and proper deployment procedures as well. To me this tool was all I could ever ask for and more. After spending 1 year on the job, I went from loathing my work to now enjoying it.

Oh, you think that was all? You think the implementation of this cool automation tool sprouted flowers with singing birds and dancing squirrels? No, not in the least. If anything, it made my cube a red target. I became the guy to hate. Yes. The developers hated the new process. They hated the restrictions. They hated change. It didn’t matter that this process re-inforced our audit procedures. It didn’t matter that this new process guaranteed us a solid code-base. It didn’t matter that this new process gave them all the tools and reporting they ever wanted. It didn’t matter that they went from being supported by 1 guy, me, to a team of 7. None of that mattered because the process sucked, and I sucked for forcing them to use it.

This is where the real battle began…