Monday, August 2, 2010

Rapid Tool Development Process

At some point we've all been to build a custom tool to do some specific task, or you end up in a situation where a small bit of automation will help reduce the number of hours spent on a task significantly. Now there are many flavors of software development processes and what I discuss here is not a new team process, if I was going to advocate a team process I'd recommend Scrum with a good Scrum Master, but each situation is different. Now, for a quick automation tool you typically need to deliver working software as quickly as possible with minimal impact to the "regular" work you have to do.

The best process I have come up with to date uses some of the processes from XP and Scrum programing processes, but focuses on project breakout and functionality building (there may be an actual process like this already, but I haven't read about it yet). The analogy I would use is building a fence.

When you build a fence you start with the general idea of where you want the fence to go. It's similar to knowing what you want the tool to do in the end. For example, you want to create a tool that automates the testing of an excel report by comparing the values in the report to an Analysis services cube. Now you can start from scratch and try to code all the way to the end, and some people may be able to do this, but for the vast majority of us mortals it's best to break this up into multiple tools.

This is the second step in the fence analogy, planning where you want the fence posts. When thinking of the whole tool try and break it out into smaller tools that you can automate easily that will either allow you to have several small steps or several pieces of reusable code when finishing the automation. For our Excel test automation tool this could be broken out into: Reading a report, determining how a cell value is generated, Reading a cell formula, and pulling data from Analysis Services. There are probably more, but this is a good start.

So now what we have is a list of ideas or smaller tools that comprise our overall goal. One thing to keep in mind while determining the breakout of the tool is to focus on something that you can use when you're done, it may not result in the automation tool you wanted when you started, but you can show progress on a regular basis if you need to, plus this allows for multiple break points during your development process allowing you to work on your everyday tasks.

Once you have built your smaller tools you can focus on the final part of the project. To go back to our fence analogy this is connecting the posts. This task is not going to be an easy one, but it with the tools you've already built a good 80% to 90% of your code should already be developed, all you are doing is linking the individual parts together. This could take some tweaking based on how you put coded each tool, but in my experience the modification required here is minimal.

One critical rule to follow throughout this process is to stop often and think about what you are trying to accomplish and what the time to impact ratio is. If you get stuck repeatedly maybe it's time to bring a contractor in for a short time and get version one out the door for you. Really keep focused on what your efforts are saving you or your team/company. If you have to spend 40 hours a week for 5 weeks and this is only going to save you a few minutes a day then maybe you should rethink what you are trying to do. I will be the first to advocate that learning something new is cool and fun, but you probably have a regular job that needs attention, plus family and friends. So pouring 80 hours a week into something that will take several years to see ROI may not be the best use of your time. I have seen VBA tools have significant impact though. I've reduced testing time on Excel reports by 50% just by creating a few tools that helped do some of the repeated tasks done during each test period (the gain was measured in days and hours, not minutes, these were huge reports).

Also, don't give up on your project. It may seem like a huge mountain to climb at first, but just focus on creating that first fence post, then the second. Even if each individual piece of code never get joined you could still end up with some simple tools that save you a lot of time.

Don't get stuck in a rat hole either. If you find yourself spending days trying to solve one problem, maybe it's time to move to the next piece. Sometimes stepping away from the problem helps you solve it.

No comments:

Post a Comment