The Curse Of Good Ideas

There’s a somewhat inevitable drawback of ideas that work out well – they continue on much longer than you anticipated. Such is the case with the mess of AppleScript, UNIX commands and Excel spreadsheet that makes up our engineering statistics tracking system. It tracks bug counts, test coverage, velocity etc over time and produces a bunch of graphs that we can look at and try and work out what they mean. It’s by no means mission critical but it is interesting to see what’s going on from day to day. The trouble is, now that we’ve come to like having those graphs, the fact that this mess of scripts can only actually run on my laptop is something of a concern.

So over the last few days I’ve been converting the mess of AppleScript over to a much nicer bash shell script to retrieve and store the data and some PHP scripts to generate the graphs. It’s come up really quite well in the end and it’s a lot more maintainable than it was. As an added bonus, it can all happen from a cron job now, requires absolutely no user intervention and doesn’t require me to not touch my laptop while it extracts the graphs from Excel via AppleScript GUI scripting. On the down side, the graphs just aren’t as pretty as Excel made. If only someone would fix fonts on Linux once and for all.

There are a number of systems like that floating around – not all in as bad a state, most at least run somewhere other than my laptop – never really intended to take off but somehow succeeding anyway. Heck, the wiki that our entire company uses and depends on was originally a quick prototype to see if you could embed EditLive! into JSPWiki. No one really saw that going company wide, I’m not even sure what prompted people outside of engineering to start using it, yet somehow it took off.

I’m still not quite certain if it’s wise to have some discipline and think about the anticipated goal for an idea if it is successful (ie: stats have to run automatically every day, even if I’m not at work with my laptop, so don’t write it in AppleScript) or if you should just do the simplest thing possible to test out the idea then change later if it does work. XP tends to say you should do the simplest thing possible, but XP also tries to keep the cost of change low – via test cases, refactoring etc. When you don’t have the tools and/or skills required to do the simplest possible thing with test cases and keeping the code clean etc, what do you do? Stopping to acquire the skills or tools is likely to take longer than just doing it the more complex way, doing it without tests means you’ll probably have to throw it out and start again if the idea works and doing it the more complex way takes too long so you may not find time to do it.

My best thought on this is to do it the simplest way possible but write down ahead of time a set of criteria you’ll use to decide if the experiment was successful or if it was unsuccessful and when you’ll review those goals. Once you reach that point, either throw it out immediately if it failed or rewrite properly it if it succeeded.