Not writing a tool helps me save time
Today I had a task of modifying an existing text file 16 times and saving the file 16 times . The change was pretty simple - just changing a line that looks like this:
file=c:\location\file001.txt
to
file=c:\location\file002.txt
and the same pattern for 16 instances. Then each file had to be saved with a similar naming structure:
import_location001.txt
and so on for all 16 files.
As I was using notepad to make these changes, I started getting bored with the repetitive nature of this task. And any time I start getting bored, I start thinking of a tool to do this. The tool here would be pretty simple to write since the changes needed to the text file were trivial and the naming convention could be handled within the same loop.
But I did not write the tool. Since I knew exactly how to modify the files, and since the files were small enough that I did not need to search through them to get to the line that needed changing, I knew I would get done in about 2 minutes, maximum. By the time I booted Visual Studio, wrote the code and compiled I would easily spend a minimum of 10 minutes. So I decided not to write the tool since that would slow me down.
Now there is a reason I would have written the tool, though. If this was a task that I needed to do daily, or even more than 5 times, then the expense of creating the tool would have been worth it.
There is no rocket science for this type of decision. It can get blurry if a tool starts to take weeks to create - you really need to understand what the opportunity cost is and whether the investment is worth it for the long run.
That gets more into basic project management and this is important to the test team as well. I just thought this one little example of NOT writing a tool might make this a little easier to understand. Too often the default action to take is to write code to solve these little problems, but sometimes that is not needed and is even a poor use of time.
Questions, comments, concerns and criticisms always welcome,
John