It's so easy to get comfortable in your everyday surroundings, but you should know by now that change is often right around the corner. In a larger sized organization, change can be difficult to implement with minimal disruptions, but it can be done, and to the benefit of everyone.
No one likes change. Regardless of what development organization I've been a part of, that statement continues to be true – no one likes change. Revision control systems were created for just this reason: users were clamouring, “if we need change, let's at least track it”. Entire frameworks like CMMI have been designed expressly to encourage systems administrators to track change. But how can we encourage change, knowing the resistance we'll start off with?
In my case, I wanted to introduce a code review tool (ReviewBoard), and process to the software development teams. Build engineering is about more than just compiling code and assembling installers, it's also about software engineering: helping developers improve their development practices. In my organization, much like many others, the issue was resistance to change.
No One Likes Change
The first thing to understand is our truism, no one likes change. Developers are comfortable in their routine, comfortable with their processes and their tools; even if things can be better, the key is comfort – people are already used to what they're used to. Introducing change means minimizing the fallout, minimizing the pain associated with a change in environment, in tools. We have to understand the user, and anticipate their pain points. We need to go out of our way to ensure our change is making people's lives better.
Fear of the unknown leads most people to avoid the unknown, and the same is true of developers. People fear extra work, different work, and the tracking of work, all things a code review process can highlight. In the case of my code review tool, what appeared to be a fear of extra work, due to code reviews, boiled down to a fear of reprisals for writing bad code. But in both worries, you can hear the same thing: how will this change affect me?
Preparing Your Environment for Change
Caterpillars morph into butterflies, but first they have a cocoon. The same is true when engineering change, you need a cocoon. Process and tool changes need to happen in a controlled environment, one we, as Build Engineers can control. In my case, I turned to my sympathetic user; you know the type: loves writing software, gung-ho about possibilities, and willing to be a guinea pig. I approached him in the hopes he'd help be my guinea pig, help me learn all about the tools I was proposing and its affect on my team.
The next key in preparing your environment involves understanding your customer's viewpoint. Application developers and their management represent our internal customers, those customers need us to minimize the associated cost of implementing our new tool. Cost can be measured in time, in impact, and even in perceived change; All this can be most easily understood by getting in the mind of our customer, the developer.
Whether you're proposing a new build system, revision control system, or a code-review tool, the key is to understand how it will affect your developers. How can developers utilize our new tools and processes with minimum interruption to their existing workflow? While introducing ReviewBoard, I tried to make the review process as seamless as possible, by attempting to have code reviews created on commit to the revision control system. This stems from my belief that developers spend the majority of their time with two tools: their editor/IDE of choice, and their revision control system client. By integrating ReviewBoard with Subversion, ensuring a review could be created as part of the commit process, I helped reduce the potential workflow change, something that helped gain the sympathy of developers towards the new tool.