Tire kickers

I've been thinking recently about different reasons to do prototypes and how I can better categorise them. Some, like recently, are a good way to do incremental or experimental work on a larger project. Others are functional, like these link checking prototypes; you just want to get something done with the smallest unit of code you can. And perhaps my favourite (yet most dangerous) prototypes are ones that explore an idea. I like these, but they often explode into day-long (or even multi-day) projects.

There's one other kind of prototype that I've found surprisingly useful: tire kickers. A tire kicker is when you make a prototype where the goal isn't the prototype itself, but evaluating the environment you make it in. For example, this Floyd-Steinberg prototype used AWS Lambda, but otherwise it was identical to my earlier Floyd-Steinberg prototypes. I didn't have any kind of burning need to dither Yao Ming's face at cloud scale, I just wanted to use Lambda for something and see how it was. Ultimately, I found out the answer: good, but rough around the edges.

Once I started thinking about tire kickers as a distinct category, I realised that's what a lot of my prototypes were. I tried out PureScript, Pony, Haskell v Rust, Elm, and of course Lambda. In every case I learned a lot, and in fact when I haven't done any prototypes for a while the thing I've missed the most is the regular exposure to new tools and techniques. However, even though I've gotten a lot out of them, I think I can do better.

The thing is that you don't want too many points of articulation: if you are working on a new idea in a new language, you're not going to know whether the idea or the language is responsible for the outcome. When I worked on the Haskell and Rust protoypes for the Beyoncé numbers, I was solving the exact same problem in two different programming languages and it made it clear just how good Rust is at mutating stuff quickly. On the other hand, the Pony project really didn't work at all, partly because I was trying to figure out how I wanted it to work and figure out Pony at the same time.

So this is the critical feature of a tire kicker: it's a problem you've solved before and are very comfortable with. I've heard a similar thing about evaluating sound equipment, that it's a good idea to have a few songs you've listened to a bunch of times and know really well. Of course, you could just randomly shuffle through your music, but you'll get much better information if you're comparing the same thing each time. By analogy, the most useful thing if you want to evaluate new tools or programming languages is have a small library of tire kickers that you're really familiar with.

I think Floyd-Steinberg is a pretty good one, as is the hosts file mangler, and my friends over at Prismatik have a nice one involving flaky webservices. That said, I expect the choice of tire kicker is going to vary a lot. Depending on what kind of work you want to do, a webservice tire kicker might be amazingly relevant or totally useless. Beyond that, the kind of problems you find easy will probably be down to your individual skills and preferences. Much like a music library, a tire kicker library is a personal thing.

Meanwhile, I've got some valuable new ideas to bring to my prototyping process: clearly, the times when I try to kick the tires on some new tools and do something interesting have been way more difficult and less useful than doing either individually. From now on it's one or the other for me.