Justifying Automation

One of the topics that comes up in my Productive Programmer talk about automation is how to justify it. Sure, everyone knows that automation is a Good Thing. And, if you can demonstrate that you can automate something as fast as you can do it by hand once, that's a total no-brainer. But what about the grayer areas where you aren't sure how long its going to take to automate something, and you aren't sure if you can justify the time it takes to the Powers That Be?

I have a couple of strategies for this that I'm including in The Productive Programmer book. First, make sure you timebox your efforts. Even if the end result of the timebox is that you create another one (because you've made such good progress), that prevents the automation from turning in to a week-long exercise when you thought it would just take 1/2 a day. Timeboxing also cuts down on the inevitable yak shaving that goes on anytime you start experimenting with something you haven't done before.

Automation is all about risk mitigation. For the thing you are thinking about automating, ask yourself the following questions:

• How long does it take to do it by hand now?


• How many times are you going to have to do it before the end of the project?


• What is the consequence of doing it wrong one time (i.e., forgetting a crucial step)?

If you take the product of the first item (how long does it take now) times the second (how many times are you going to have to do it), that tells you what kind of time investment you have now. If that time investment is longer than what it would take you to automate it, no brainer again: automate it. The third item is about risk mitigation: if it's disastrous if you miss a step, that should make you lean towards automating it. For example, I was on a project not long ago where (for bizarre historical reasons) they didn't want to separate the compiled versions of their tests between unit, functional, and integration. Their solution was to create hand-crafted test suites. But, that means that we have to remember to add them by hand every time we created new ones. That's a big risk: I'm never going to remember that! Instead, we automated it by creating a little Groovy script that ran at build time to auto-generate the test suites based on the root directories. The risk of not automating this problem was wasted time: we wrote a test and forgot to include it by hand, meaning that we don't get the benefit of the test and thus wasted the time it took to write it.

I'm curious if others have tried-and-true strategies for justifying automation...

From Architect to Wrangler

One of the nice things about ThoughtWorks is the ability to create your own title, which leads to some interesting business cards (like a title of "Seat Warmer"). But, the restriction is that you only get one set of business cards, so choose wisely. Instead of going nuts on my first set, I chose the ultra-conservative "Application Architect", which is a reasonable approximation for what I do on projects.

But now I've changed. The title of "Architect" for software developers has gotten so diluted that its meaningless anymore. In fact, its almost pejorative because so many "paper" architects give it a bad name. I've gotten "Oh, dude, I'm so sorry" looks from people when I tell them I'm an architect, assuming that I've had a head injury or something and can't do real development work anymore. After long formulating and advice from others, I've now changed my title to the probably more apt "ThoughtWorker/Meme Wrangler". As you've probably noticed, I love the "meme" meme (after all, you are reading this on the "memeagora" blog). While it's a little cutsy, at least I'm not treated as a tragic has-been by coworkers and clients.

The interesting side effect of this happens because I put my title on my presentation slides. In the US, but particularly overseas, people ask me "What does mee-mee wrangler mean?" So, I get to explain it.

But that's way better than the now deprecated "Architect" title. It's a shame that, because we have no real industry-wide certifications, the nominally most advanced title has been co-opted by so many people divorced from reality. I've had to defend decisions made for SOA initiatives in front of "Architectural Review Boards" by people who last wrote code in COBOL. Can they really make good decisions about modern technology if they never touch it?

Git along, now, little neuron...

Keeping Knowledge in Plain Text

The book The Pragmatic Programmer is absolutely worth re-reading every few years, because every page has stuff on it that's still relevant. One of the important lessons is "Keep knowledge in plain text". To paraphrase, you shouldn't keep important information in a proprietary piece of software, because if the software dies (because the company goes out of business) or it relies on a changing protocol (more about this in a second), your knowledge is trapped. If you keep it in plain text, you can read (and manipulate it) using a lowly text editor.

Two things made me realize this in a Big Way recently. The first was my ToDo list. I used to keep all my ToDos in a good (but fatally proprietary) piece of software named LifeBalance. It's the best of that category of software, but using it meant that I had to have a Mac OS X, Windows, and Palm client to access it. It became its own project just to keep it in sync. And, unless LifeBalance works instantaneously, adding items takes time. I was reading the LifeHacker book (distillation of the awesome LifeHacker web site) earlier this year, and one of the first items is an entry about a text-based ToDo list manager called ToDo.txt (which has its own website). It's called "Task tracking for command line lovers". The nice thing about ToDo.txt is that it uses a plain text file for storage. And, the author has written a bunch of bash/batch files to help manage it. That means you can append stuff of your own (using QuickSilver, in my case) or you can use the tools. The command line tools also let you prioritize, archive, and a bunch of other stuff. It's a good marriage between command line and plain text.


The other driving home of the important "Keep knowledge in plain text" lesson concerns my blog. For years, I just wrote my blog entries in a text editor in HTML and uploaded them by hand to Blogger. Last year, I fell for a seductive blog editor/manager called MarsEdit. It works fine, allowing you to create drafts, view your blog, handle multiple blogs, etc. The way it did this was via using one of Blogger's APIs for managing blogs.


Then something terrible happened: Blogger changed their API. Suddenly, MarsEdit didn't work anymore. Posting new entries wasn't a problem because I could go back to doing it by hand, but what amount my 9 months of existing, historical blog entries it held? Trapped! Now, I can't use it, and I can't easily free all my information. I violated the rule!


I just spent a couple of hours fixing this mess, re-syncing my original directory structure by hand (at least I was able to use wget to slurp my whole blog down to my local machine, making it much easier). I've felt the pain of violating the rule, and I promise not to do it again. My last step was removing MarsEdit from my machine (which, BTW, has now updated itself to work with the new API -- unlike our president, I remember the phrase "Fooled me once, shame on you, fooled me twice, shame on me").

Of course, Dave and Andy already knew this, and they told me, but I wasn't listening. Sometimes, you have to suffer for good advice to take hold.

Don't Be a Hater -- Think Different

People still fear what they don't understand or what's not familiar. When I arrived at the SOA conference in Kuala Lumpur a couple of days ago, I was met by the hotel's AV guy to hook up my Mac to the projector. I used the normal elaborate procedure I usually do to sync my Mac with a projector: I plugged the projector into my machine. But, unusually, no signal. I tried Display Preferences, changing the resolution, the number of colors: nothing. He was convinced that my exotic, bizarre machine/OS was the problem, and I kept trying to convince him otherwise. Finally, I persuaded him to go get another cable, which he reluctantly did (I don't know any Malay curse words, but I'm pretty sure I've now heard some). You can probably guess what happened next: new cable, perfect signal, at all my original settings.

Which reminded me of another conversation I had a couple of years ago with a friend in Singapore. We were sitting around talking about computers, and he made an off-hand comment that he didn't like Macs because he thought they were unintuitive, but he thought Windows made perfect sense. So, I asked him "So, you're telling me that the operating system where you click on the Start button to turn it off is the more intuitive on? I think you're just used to it", to which he replied: "You're right, I'll shut up now". I saw him again last night in Singapore, and we were catching up on all sorts of stuff. And you know what he told me? He just got a new machine with Vista on it, used it for 2 weeks, and returned it to Dell. He told me that he can't wait until his laptop finally dies because he's going to get a Mac. The reason for the change? He's now addicted to his iPod, and it's made him realize that Design Matters.

I can't resist beating everyone on the head with the moral: Don't succumb to FUD because something is different. And, in the tortured grammar of the old Apple campaign, Think Different. Because Vista is so different from previous versions, it may be the best thing that ever happened to Apple. If you're contemplating a change anyway, why not look at the entire field so that you end up with the OS equivalent of an iPod, not a Zune.

Pontificating about SOA

What else is there to do about SOA? Back in December, Mark Richards (Enterprise Architect at IBM) and I sat down and recorded a video PodCast about SOA (which we informally named "Taking Back SOA"). The results has now appeared at the No Fluff, Just Stuff web site. Mark and I have a very pragmatic approach to SOA, and we both hate the level of hype that appears in that whole space. He and I had a great time recording this video, which proves once and for all that IBMers and ThoughtWorkers can get along after all!

No, I Won't Stop Talking about IntelliJ!

During my No Fluff, Just Stuff talk on The Productive Programmer, I got a comment at the Minneapolis show to "stop showing us IntelliJ shortcuts -- we all use Eclipse!" And, Venkat Subramaniam blogged about the whole Eclipse vs. IntelliJ debate that came up at the expert panel in that same city. Venkat quite eloquently gives his reasons for choosing IntelliJ: it simply makes him more productive. And the same is true for me. I've used all the major Java IDE's in anger: NetBeans, JBuilder (I used to be considered a JBuilder expert, but I got over it), Eclipse, and IntelliJ. For me, IntelliJ works best. Period. In fact, I think that IntelliJ would land in my top five pieces of software of all time list. I also edited the No Fluff, Just Stuff Anthology chapter on IntelliJ tips and tricks, just out in treeware.

There are actually 2 IDE Tips and Tricks chapters in the anthology. When I sent out call for contributions from the authors and friends for IntelliJ tips, I got a flood of them, all very cool (and a few that I didn't already know about, like the Key Promoter). Ted Neward (who edited the Eclipse chapter) and I sent out the same call for Eclipse tips and tricks, and we got none. We sent out another call, and a few trickled in. And that is reflected in the book. I'm sure we're going to get grief over the IntelliJ chapter having more cool stuff. But that's really the whole point: like the preponderance of Macs on the No Fluff, Just Stuff tour, the people who use IntelliJ are passionate about it, because it exudes excellence. Like Venkat says, many people using Eclipse are in a bad arranged marriage. It's hard to drum up passion for an arranged marriage.

I feel like it is my duty to try to turn people on to things that make their life better. That's part of what being a speaker is about. So, I'm not apologetic about proselytizing IntelliJ. Every-time I find a tool that I think will make developer's lives easier, I'm going to talk about it. And, if I develop a passion about it, so be it.

PodCasting About Groovy

A couple of weeks ago, I recorded a PodCast for AboutGroovy.com, talking about (obviously) Groovy, DSLs, testing, and how to insinuate Groovy into your company's infrastructure. Basically, Scott Davis and I had the kind of conversation we have all the time at No Fluff, Just Stuff. The only difference is that he was recording it. It was fun and the content will come as no surprise to anyone who knows me.

Being a Consultant Makes You Tough (or Stupid)

Since working for ThoughtWorks these 2 years, I've gotten much tougher in the face of being able to work on short or bizarrely interrupted sleep. Case in point: I left Minneapolis (after speaking at the sold-out No Fluff, Just Stuff Twin Cities Software Symposium) on Saturday evening, dashing from my last session at 4:45 straight to the airport. 8 hours later, I was in Amsterdamn, with a 2 hour layover. 12 hours after that, I'm in Kuala Lumpur, arriving at 6:15 AM. I probably got about 8 hour of sleep, but never more than 2 hours at a time. I'm now exactly on the other side of the world from where I live: 12 time-zones away. I cleared customs, got my suitcase, and headed for the car service the conference had arranged. Traffic was awful, and combined with the distance of the airport from downtown KL, I arrived at the hotel at 8:35 AM...and the conference starts at 9 AM with me facilitating. Quick shower, dash upstairs, and I'm ready to go at 9 AM sharp. I then proceeded to talk on and off for 8 hours. I managed to stay up until after 8 PM. It's now the next day, and I feel fine. I'm apparently adjusted to the new time zone (I sleep soundly last night, interrupted only by my phone ringing at 11 PM (or, 11 AM in the states)) which I promptly ignored.

Two years ago, I could have never done this. Just part of the implicit training all the travel and distributed work instills. But there are benefits as well. Here is a picture taken just outside the hotel's meeting rooms.

The Elusive Right Click

Since he got his Mac, Venkat Subramaniam and I have been playing around with pushing the envelope on human computer interaction and productivity as hard as we can. He finds a cool new keyboard shortcut and can't wait to tell me, I learn a new QuickSilver bit of magic and can't wait to tell him. The Holy Grail of this kind of pursuit is finding a way to generate a mouse right-click using only the keyboard. Of course, Mac OS X is pretty friendly to use the track pad, but that's not enough for us: total keyboard control is the goal.

And yesterday I stumbled upon the Holy Grail. I was in the process of shaving a yak, and was waiting for something to finish, so I decided to solve this problem Once and For All. I did a bunch of Googling and experimentation and stumbled upon the solution. Go to Universal Access and turn on Mouse Keys. This the the accessibility option that allows you to drive the mouse strictly from the keyboard, using the embedded keypad. Once you turn that on, you can use the FN-I key to click the mouse, which means that you can use FN-CTRL-I to right click. It's not perfect (it clicks where the mouse current resides, not where the keyboard focus lives) and it precludes using the embedded numeric keypad for doing 10-key entry (which I never do anyway). You can turn it on and off by clicking the OPTION key five times (this is a setting on Universal Access as well).

But we're happy. Venkat got as excited as I've ever seen him when I showed him this morning; I was looking forward to show it to him all day. Ah, simple pleasures!