Did you forget your: Username / Password ?

Microsoft

TechWell

Home

Behaviorally Speaking

Behaviorally Speaking—Tools

Written by Bob Aiello

Monday, 13 February 2012 00:00

There are many great jobs in IT, and one that I always put high on my list is the toolsmith. I love getting new tools to study, implement, and support. Sometimes, it is hard to believe that my clients pay me to play with toys! But supporting legacy (outdated) or difficult-to-use tools can be a nightmare. Some of the version control systems (VCS) in use today are so bad that you can actually lose source code or changes that you thought were safely stored. Tools experts are often expected to be experts on the selection, evaluation, and implementation of tools. This article explains what I have found to be successful with adopting tools.

Start with the End
It may seem intuitive, but you need to begin this journey with a clear view of where you want to be, and that starts with understanding your goals. Are you supporting a small team that requires some light version control or an experienced cross-functional team that would thrive on powerful tools with advanced capabilities? You may take many stops during this journey, but you will achieve success better if you start by understanding where you want to be.

Defining Evaluation Criteria
Tool evaluations need to be perceived by all stakeholders as being fair and impartial based upon objective and valid criteria. You need to define this criteria in a way that makes sense for your organization. I usually start with understanding the technical capabilities required in terms of supporting sandboxes, branching, and merging. Considering the integrity of the repository and security logging of change history is also essential to comply with commonly accepted audit and regulatory requirements. Understanding the learning curve and effort to administrate the repository are usually high on my evaluation list, as well. Because you may have a different list of criteria than I do, you may need to ensure that you identified the factors that are most relevant to your organization. You also need to consider if you can afford the tools that you want to select.

Budgeting for Tools
Evaluating the total cost of ownership requires that you consider the cost of vendor maintenance and support—the necessary hardware along with the purchase price of the tools themselves. You may need additional support staff, consultants, and other resources in order to adopt a particular toolset. Your budget should take into account the entire cost of ownership and perhaps savings from being able to retire other legacy tools. You may also be able to quantify return on investment (ROI) by calculating the value of increased productivity and quality.

Return on Your Investment
If you expect to spend money on tools, you need to consider how you will show ROI. I had a CTO explain to me that he was painfully close to losing a million dollar deal because of source code and release management problems. I learned that his team kept making mistakes, in part, because they were not using tools that matched their capabilities and objectives. Obviously, it was easy for me to show a return on his investment, but it’s not always this easy. Usually, you have to justify tools in terms of increased productivity and quality, which may or may not be possible to quantify. You also need to realize that free is not always the best price.

Is Open Source Really Free?
Too many people have a narrow view that open source tools are free of cost. Actually, some open source tools require that you hire an expert consultant to create scripts and wrappers just to achieve functionality that comes standard with commercial products in the same space. For example, Subversion and Git often require custom hooks to enforce features that often come standard in commercial tools. You also may find that you get what you pay for when it comes to features, especially repository integrity. Open source tools sometimes require much more support and may have limited capabilities.

Training Is Key
Make sure that you consider the training necessary for successful adoption of the tools that you select. You may have to pay for this training, but it will cost you a lot more if your team struggles with learning how to use the tools that you select. Selecting the right pilot project and participants is also essential as to determine how a given tool might be utilized by your team.

Pilot Project and Participants
I usually look for an important project that is not too complex as my pilot. More importantly, I like to select participants who are truly open minded and excited to be involved with this effort. Be careful with selecting participants; I once had a volunteer actually have an agenda and was motivated to derail the evaluation. Consensus is great, but leadership is also very important. You need to show not only the capabilities of the tool but also a clearly defined use case for how it will add value on a day-to-day basis.

Defining the Use Case
Explaining how the tool will be used on a daily basis is an important way to ensure that all stakeholders its features. Too many people only focus just the capabilities of the tool without taking it a step further and considering how all of the users will interact on a day-to-day basis. Even if the tool is less than perfect, you may still be successful if you explain how to work within the product’s capabilities and limitations. I always tell people that I would rather know about any bugs and issues with the tool so that I stay clear and not discover these issues the hard way.

Conclusion
Tools selection is a fun and exciting task. You need to establish objective criteria as part of your evaluation and conduct your pilot in a transparent and cooperative way. Make sure that you consider the total cost of ownership, define a comprehensive use case for adoption, and focus on training. Make sure that you drop me a line and share your challenges and success with tools evaluation and implementation!

About the Author
Bob Aiello is a consultant, editor-in-chief for CM Crossroads, and the author of Configuration Management Best Practices: Practical Methods that Work in the Real World, Addison-Wesley Professional (http://cmbestpractices.com). Mr. Aiello has more than twenty-five years’ experience as a technical manager in several top NYC financial services firms where he had company-wide responsibility for CM, often providing hands-on technical support for enterprise source code management tools, SOX/Cobit compliance, build engineering, continuous integration, and automated application deployment. Bob has served as the vice chair of the IEEE 828 Standards working group (CM Planning) and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) management board. Mr. Aiello holds a Masters in industrial psychology from NYU and a B.S. in computer science and math from Hofstra University. You may contact Mr. Aiello at bob.aiello@cmcmedia.com, link with him at http://www.linkedin.com/in/bobaiello,or visit his corporate website http://yellowspiderinc.com.