#AltDevBlogADay

There are so many things to remember when building tools that forgetting one part can result in a big waste of time.  Personally I’ve seen this happen, and in some instances wrote tools myself that we’re never used.  Although it’s something I strive to eliminate, being new to tool creation has it’s lessons to learned, and I have learned a considerable amount of knowledge from these failures.  In this article, I’m going to try to outline a list of things I try to be aware of when making tools for others.

How do you decide when you need to write a tool?  When does it become nessecary to take time to write a tool?  This is a hard answer to define,  but I’m starting to believe you can only understand it after you’ve written 1000 scripts.  Similar to the mind of a great artist, this type of subjective opinion comes with experience.  But, if I had to put an all-encompassing answer to that question, I would say, if the answer to any of the following statments is true, You need to write a script for it.

• if the time it takes to write the script takes less time than doing the task manually.
• if you are constantly doing the process over and over.
• if doing said process gives you a headache
• if there is a lot of chance for human error
• if the process is mind numbing

I understand there are many instances that fall outside of these categories that should be scripted, but when I answer yes to one of those statements, the scripting lightbulb goes off in my head.

So we’ve decided that it’s time to write a script, how do we go about writing it?  I’m going to leave out language specific concerns and focus on the big picture ideas.  The most important thing when writing a tool for someone is knowing upfront what they expect the tool to do when you finish it. There are different approaches to solve this problem, but I find having a meeting to discuss the  functionality and an UI is the best way to keep everyone on the same page.  Without this meeting, you’re in for a world of trouble.  You can try to do things like assume you understand what they want, but I find that sitting down with them for a few minutes asking questions, listening to the answers, and regurgitating them back, saves you hours down the road.  It’s difficult to think like someone other than yourself.  If you’re making a tool for an artist, and you’re a programmer, you probably have extremely different ways of thinking.  This is one of the reasons I believe making tools for others is much harder than making a tool for yourself.  If your making the tool for yourself, you know exactly what you have to do to make the tool work, and what you’re not going to stray away from that process.  When making a tool for someone else, they’re going to click every button you put on the program in every order you can think of.  To solve this, you have to think like them.  This sounds easy, but is one of the hardest things I’ve found when making tools for others.    Before I began interrogating the user of my future tools, I used to just get a small idea of what they wanted, go to work, and once done, I’d deliver it.  Most times, they would come back to me with either some crazy error, they wouldn’t understand how to use it, or they would want the UI changed.  I have gotten better at this through experience, but extensive questioning up front will really save you a headache down the road.

I don’t want to get into the programmer/scripter argument, but I think that programmers have a tendancy to want to make the coolest baddest tool from the get go.  This is an older waterfall methodology, but for scripting I believe agile programming is the way to go.  The idea is simple, build your tool incrementally and add more features to it.  In my opinion, the best part of this methodology, is that your always have something useful.  Even though it might not be totally feature complete, you’re not waiting around for 3 months with only a half-built system.  So even if it’s not done, you may be able to automate 60% of the task and have to manually do 40% of the task.  This saves time, and you don’t find yourself waiting on that tool that was supposed to be done 2 weeks ago, a month down the road.  I like to think of this as the Minecraft Methodology.  Build small, and continually add on to it, which brings me to my next topic…

If you’re doing agile programming, you have another great plus, the ability to test very soon into development.  This allows you to make sure your client is up to date on what you’re doing and will help make sure that everything is on the right track.  Nothing is worse than finishing up a tool and the client says it wasn’t quite what they were looking for.  Testing often, gives the feedback to make sure they can’t say “It’s not quite what I was looking for,”  Anything that’s wrong will be caught in the first few iterations of the tool.  I’d like to believe people get excited for new features, and to see the tool progress to it’s final stage.  Another thing that helps by testing often is that as a programmer you can become blinded by what you believe is the “way the tool works.”  What I mean by this is bugs that happen because of how you wrote the tool.  Maybe you never tested to see all the wierd errors that happen if a certain combination of buttons is pressed.  Testing often will allow you to see how the client uses the tool, and give you time to fix it before the next release.

I wish I didn’t have to have this as one of my scripting mantras, but I feel like there are a lot of people who just want to get things done as quickly as possible.  I have no problem with this as I think most people want things to be done quickly, but there is a difference between getting it done quickly and slapping it together.  Each tool you write is experience towards making tools, and I think taking some time to understand what your doing is essential to getting better at writing tools.  If you take some time to learn, you are essentially making yourself more useful down the road and I believe this is something to strive for.  The second reason to write good code is maintaining code.  If you’re doing the agile programming method, your going to end up fixing things after your feedback sessions.  If you write good code the first time, then maintenance is much easier.  If you don’t, it’s going to be a major pain down the road.  Moral of the story, write good code the first time, so you don’t have to re-write it later.

I can’t quite remember who said this on www.tech-artists.org but it went something like, “Everytime you write a tool, strive to learn one new thing.”  I understand sometimes you just need to get the tool done, and learning isn’t that important, but if you learn one new thing every script, I guarantee that in a year, you will be much more employable and you will see your tools become better.  This one bit of knowledge has increased my love and skill for creating tools.