Recently, I posted on how to justify investments on development tools that help improve developer productivity, quality of work performed, etc. Any tool which talks about productivity improvement should help on two accounts – quality and quantity. If the quality of the work improves drastically (say the tool helps in reducing errors), it will also help in reducing the time taken to do testing. The same way, if it can automate the work that I am doing (eg. Code review), nothing like it (except that it makes me more lazy!).

Now, let us play the devil’s advocate: Do tools really help in improving productivity? This question is asked quite frequently – not just from the decision maker, but also from the end user community. There is a request for investing on a tool from a developer/team. Another team questions this and there is a reluctance in using the tool. Sitting on the hot seat, you start wondering about these purchase requests. On top of that, tool adoption takes more time than what is originally planned. This makes the investment on tools (in general) questionable. So, what can help in the successful implementation of tools?

Successful implementation of tools depends on change management, perception of usage benefits, time of introduction, etc. Let us take a closer look at this, through a few examples:

• As we know, there are plug-ins available for developers… there is a bugzilla plug-in available for Eclipse, SVN plug-in available for Visual Studio, etc. These tools help to save time – you don’t have to switch between your issue tracker and IDE. Also, it reduces errors. Sounds good, doesn’t it? However, what I’ve noticed is that people have a misconception about the savings that one can get by using these tools. If there is a saving of 3 minutes, 5 minutes here and there, people don’t perceive the savings as real. But, if you project it in terms of how it can reduce the errors or how it can help the developers, the reception is far better.
• There are good reporting tools or plug-ins available which can work within your issue tracker. Often times, project managers are too focussed on putting out day-to-day fires and give lower priority to performance analysis – say, bug analysis to find root causes, problematic areas which require change in approach, etc. Again, there could be tools available which can readily help here. So, it requires some amount of convincing.
• Similar thing goes towards using ready-made components (eg. infragistics, telerics, myeclipse, etc.) or tools from different vendors. I understand the dependence on a 3rd party vendor while developing your product. Each ISV may have their own principles and thought process towards these. But, if it can help you crash your development timeline, why not?

So at what point of time do you automate / introduce your tool? I have seen better results if we try to do the things manually before automation. In our organization, we do a lot of research and analysis on our prospective customers, prospective employees, etc. Also, similar thing happens for analyzing defects, variance, etc. We have tried different approaches here to automate. In certain cases, we have automated activities directly and have seen them fail. Failure is not because there is a problem in technology. The problem was in realizing / perceiving the benefits of using these tools.

In cases where we put in procedures for manually doing things, it worked well…we would have identified problems, challenges in doing things manually and we would automate exactly what is required. Doing things manually also gives you an opportunity to streamline the activities involved. After all, your automation is only as good as your process. So, once people do things manually, they know the pain points and then we bring in automation tools – it leads to easy adoption and absorption of the tool.

So, it is the question of positioning the tool well for successful implementation. If that is done properly, we will see the ROI a lot faster.

(No Ratings Yet)

 Loading ...

Related Post

• Are you facing difficulties in justifying tools investment?