Hi, my name is Rick Wayne, and up here with me are Scott Ambler, David Dossot, Joel Spolsky, Paul Tyma, and Alan Zeichick.
I’m the New & Noteworthy editor for Software Development Magazine; I’m also a judge for far too many categories in the annual Jolt awards, a product reviewer for the magazine, and in my day job I’m a developer, for the University of Wisconsin Soil Science Department.
Yes, your taxes pay me to write software about dirt. Thank you.
All these things bring me into sufficient contact with dev
tools that they tend to engender a certain suspicious attitude, as do some of
my off-hours activities. For instance, my wife and I are pilots. Because we
both work for the State of
I’m also a ski patroller, downhill skis as well as snowboard, which might not seem germane but it affects that whole evaluating-attitude thing. Let me tell you a little about what a ski patroller does, see we have these customers—management prefers that we refer to them as “guests” rather than “suckers”, in the same way that they asked that we stop referring over the radio to a particularly notorious trail intersection as “The Boneyard”…anyway, the guests pay obscene amounts of money to attach big sticks to their feet and then slide down hills at terrifying velocities…then they fire off over a jump and shoot backward into the half-pipe.
Well, in the process bits of them tend to break off, and then it’s our job to trundle up this big heavy rescue sled, gather up the bits and stuff them in as best we can, and convey them down the hill to proper medical care or a decent burial, as the case may be.
So the habit patterns one develops from this sort of thing tend to be those of a clinical paranoid, which is exactly the sort of person you want evaluating tools. Meticulous, very anal-retentive, look before you leap, whether it’s preflighting the airplane, evaluating dev tools, or strapping some poor schmoo into a toboggan and picking my line down through the moguls.
You’re actually buying this, aren’t you?
Ha! What a load of bull! As those of you who actually work with me know, I’m more like Dory, the fish in Finding Nemo. You know the part where they’re going to go through the trench, and Marvin wants to distract her? All he has to say is “Look! Something shiny!” “Where?!”
So in reality, the people who fly with me are often so eager to do that kissing-the-ground thing that they neglect the formality of waiting for the landing…the area around Dane County Regional Airport is dotted with little lawn sculptures of people’s feet sticking up out of the ground, with their lips wrapped back over them…and the effect of this attitude when I do my job as a ski patroller need hardly be imagined.
But I didn’t come here today to talk to you about killing people. I came to talk to you about evaluating and selecting development tools, which you can use to write software that kills people.
The first suggestion I have for your tool-evaluation process is that you have one. All too often you hear conversations like “Hey, Dave, what’d you think of Framinator?” “Oh, I played with it for awhile, it’s pretty cool, we should buy it.” So you should develop a checklist, a series of hoops every tool should jump through. I’m not going to tell you what that checklist should be, just that you should have one. You know what you need.
Avoid lockin. Boy, that’s helpful, eh? That’s like saying “Deliver quality software on time”, right? Actually, if there’s no lockin, if the tool doesn’t change your environment in some significant way, give you some advantage that goes away if you drop the tool, you might as well not have it. Lockin is inevitable, but its effects can be mitigated. Lockin occurs if you follow the path of least resistance, if you’re like Dory, and adopt shiny features without considering the effects downstream.Two hills on the lockin path to consider: migration in, and migration out. How easy is it to adapt the tool to your current projects and data? How hard will it be to get back out again?
Seek information sources, but evaluate trust levels
Spread the assignment around
New eyes, new perspectives
Coveted assignment—use as incentive (Yes, Joel, I know they don’t work)
Consider pairing. Put a Marvin with a Dory; she’ll find and champion the shiny objects, he’ll minimize the risks.
On the technical end, I strongly suggest you consider virtual-machine tech such as VMWare or Virtual PC, and here’s why:
· Allows you to simulate the slowest developer’s machine (the machine that’s slow, not the…well, actually that tends to correlate rather well, doesn’t it?)
· Lets you provision a standard test environment, then deploy it for new tests within seconds
· Lets you insulate a developer’s machine from the effects of the tool and the testing delete virtual-machine file, done, and you haven’t eviscerated the real customer data on the real server.
· Lets you provision a variety of test environments, matching what your developers work in
And if you ever get out to