private override

11Nov/092

every team needs a toolsmith

the_dawn_of_man_2001_a_space_odyssey-400-400

Every software project is different, and there are subtleties associated with each one.  Every project  requires unique and specific tools, and we need someone to build them, or each member of the team needs the freedom and responsibility to do it him/herself.

I have very little (zero?) tolerance for waste when it comes to automatable processes that aren’t automated because “we don’t have time”, or “we’ll discuss it later” and then it gets dropped, or any other reason that is less than justified.

Zero Friction Development is what I’m going for here. (here is an article that I found interesting around this topic… it’s not really our fault, it’s built into our nature)

What kinds of things am I talking about?  Anything that slows down my development that can be automated away to make me a happier developer.  Whoa, wait, happy? Is that a requirement I have of my workplace?  Absolutely.  I can put up with periods of un-happiness, but long-term unhappiness is not acceptable (for me).  Oops, sorry, almost derailed there for a minute. :)

Specific frictions I’ve addressed or have seen addressed…  just so you can get an idea about the things that I’ve seen done, that might trigger an idea for you:

  • Code-diff generation – On a previous project, all the code for our product was stored in the database itself (Intersystems’ Cache), so we didn’t have a real decent way to generate diff-sets for code review.  So we wrote a tool to do it.  A previously laborious task (at least 30 minutes for a simple changeset), with much room for human error, turned into a 30-second, enter in a task number and press ‘Go’ joy.
  • Code Generation – On a previous project the best way to get where we needed was simply to inspect the structure of a piece of data, and then generate code to deal with it.  You’ve probably done this one before… many times.
  • Source Control Integration – Again with the Cache project, we needed a way to version our code using standard tools.  We wrote a tool to bridge between the file system (for TortoiseCVS, or any other VCS) and the database storage.
  • Client requires code-diff uploaded to their CMS for each completed task – Seems like a bogus business process, but it needs done.  It’s painful because their CMS is slow and clunky.  So I wrote a ruby script, paired with selenium, to automatically create a diff of my code and upload it to their CMS with some browser automation.
  • Data generation – Ever need test datasets?  Yeah, me too.  Whip out some ruby and get it done.
  • Tool integration – ever have two systems that need to be kept in sync?  Yeah, it’s a pain, especially when neither have an API.  What they both usually have though is either a command line interface or a web interface.  Both of those are easy enough to script with, given some ruby magic and some browser automation.
  • Time tracking – There have got to be 8 billion time tracking tools out there… if one doesn’t match your style, bust out a quick one that matches the way you work.  Need it to integrate, there’s probably either a web interface, command line, or API, go for it… it’ll make you happier (hmm… there that is again!).

What other things have you automated?  What are your thoughts on the toolsmith?  There is a whole book about doing this type of stuff with Ruby.  I’ve never read it, but I’ve heard it’s pretty good: Every Day Scripting with Ruby.  Another excellent book by the guys at the prag bookshelf is Pragmatic Project Automation.  It deals a lot with things we already do (build automation), but takes it further as well.  Here is an intro: Pragmatic Project Automation Intro.

For sake of full disclosure, this is not a new idea, and I’m not claiming to have come up with it.  It’s been tossed around for years, just wanted to bring it up again.

Comments (2) Trackbacks (1)
  1. Man you made me dig deep for the diff generation tool. That’s fuzzy, but now I’m recalling a shared drive with piles of before and after directories and a copy of WinMerge.

    A recent “automation” win for me came from the need to test some C# code. I needed a separate process I could call over and over, not an nunit fixture. Instead of adding another exe project to the Visual Studio solution and slowing down builds forever, I just loaded my library in a tiny IronRuby script and called it. Simple, but it automated away the ceremony of an extra project.

  2. Hey Jon,

    I like the idea of having a toolsmith and I also think it’s important for everyone on the team to see opportunities for automation. Even if someone can’t implement the solution, seeing the improvement is a step in the right direction.

    Automating is appealing to me because it makes getting into flow easier and reduces mental complexity. There is only so much energy and time, so being able to multiply a given amount of energy and time gives great rewards. It’s a morale booster to think about how much you have sped up the process.


Leave a comment