Tools that slow you at work !

Hi Reader,

Its been slightly more than a month since I started blogging and the response from you all is .... ( you must be knowing it better than me , because it is you who gave the feedback )

I have been sitting idle at my workplace for quite sometime now and as people say "idle mind is a devil's workshop" I wanted to change it as "idle mind is a tester's workshop".

Before I leave my current organization, I was wondering what are the things that slowed down my speed at work so that I could give somethig better for the company I may land up ! [ still looking :-( , any takers ? ]

While I was listing , I found something that really brings down the pace of a software engineer's speed of work ! ( inclusive of my fellow developers )

Most of you who faced the same problem could guess it right - TOOLS !

__ Tools that slow you at work ! ___

"Now pradeep , tools are used to augment the work speed and not slow down , shut your mouth and dont let your devil rule you" - if you intend to say something similar after reading this much .. pls dont go ahead reading ... still if you want to read , I am (un)lucky :D !

• Harbour problem - Well, I was once working on a tool that accesses a product via USB port. It was working fine as long as another tool which also accesses USB port was installed into my PC for a different purpose. I had a tough time figuring out how to make them co-operate with each other.Finally it ate sometime of mine , say 2 hours , had I not let this info to my team mates , a total of 2*4 = 8 man hour or even more or less would have gone in figuring out the same.
• Inconsistency problem - Not Well , Once my colleague came complaining that a tool was not working on his PC but it worked fine one mine ( I mean, my PC ). He sat on my PC for working on it and of course he too is facing a deadline , had he started digging out the solution for that particular tool not working on his PC he would have spent more time but still 1 hour of man hour lost. Now taking that every PC has a problem to work for a tool , 4*1 = 4 man hours are lost in a day. ( Of course approx values ,after all I am not reporting to anyone to give exact figures)
• Reboot Now ! - A usual stuff that needs to be done when some tool is not working and this eats around 10 minutes and happens atleast twice a day every 2 days in a week and hence 10*2*4(days in a week)*4(people) = 4 man hours in a week is lost.
• Send report ! - Whenever something crashes , Microsoft wants to see who is competing with them and you see this message of send report and we usually dont do send. This ignorance of all of us makes Microsoft unable to get the required data for solving any issues if any, due to their product.( Let's say this adds to a very negligable part and ignore)
• Tools with limited licence - This is something everyone may agree. Every company I have been has a shortage of tool license and this usually contributes to 1 hour of time loss per week per person of the company. So it is 1 * ( number of your workers) = loss time due to this factor.
• Tools that work on the server - Some tools are designed to work on servers while you are just another client to it. It simply makes you to wait invariably and you sometimes see "Time out" message. Indeed , it is "Our Time out" and not "Server Timed out".Occurs atleast once a week for a person and last for 10 - 15 mins before a person can start the work and hence , 10 mins * ( no of workers ) * 5 ( working days )= loss of time due to this factor for a week.
• Build machines - Build machines contribute to a major factor , I have not used them extensively but I have seen many people firing a build overnight and morning they see build failed half way and if it is an entire product release build , it for sure takes nearly 4-6 hours for the build to complete. Assuming that this happens once a week for every developer or a small group of testers or release engineers - 5 hours * ( no of people firing a build ) * 5 ( working days ) = total time lost in waiting for the build during day.This point is very important as developers give the build at somewhere in the afternoon and yet testers are forced to finish their work before COB ! I pray to all build machines to work well in the night.
• Drivers - I wonder most of the tools I use that interface to hardware have problems with drivers. Each time I find a situation where the hardware is not detected , I need to uninstall and re-install the driver to use that tool. Why not people come out with another tool to uninstall and re-install drivers. Simply this eats 10 minutes per session and occurs to me atleast twice a week. 10 mins * 2 ( occurence ) * ( half the number of workers ) * 5( working days ) = Total time lost in a week due to this factor.

__ End of __ Tools that slow you at work ! ___

Gosh ! taking the total , roughly 30% of our time is lost in managing the issue with tools and for the rest .... there is always ... a meeting.Amidst all these we contribute to profit of the company , isnt that great !

Learnings -

1. Tools that are to be used extensively should be tested well , else lot of time is lost and the productivity comes down by nearly 30%.
2. A tool needs more testing than a product which it is aiding to be tested/developed.
3. People observing an issue with a tool must let the tool company know it and help them to fix the issue.

"Tools that are not tested well are time bombs !"

Thanks and Regards,

Pradeep Soundararajan

Disclaimer : If you have read this despite me asking you to stop somewhere in this post you are not eligible for negative criticism ( you can , OK ). This is my own opinion with the experiences I have faced and of course I too have seen some robust tools as you may would have.All above are approx values and still is a matter of concern to every organization.The list above is incomplete :-D.