I was taken to the dogshed by my lead developer the other day. We have been building a web service api, and a javascript analytics client, both at the same time. He’d been grumbling about the service interfaces for some time; I’d resisted changing them. Finally, I noticed he was getting more and more sullen. It turned out that he was not just annoyed but really upset about the interfaces.

Certainly, they could be improved. As he said, they were “RPC-style” interfaces, despite our stated goal of following REST principles. Indeed, I had cooked them up in 45 minutes one evening. They did support the client fairly succinctly, but would almost almost certainly break if we made any design changes, or tried to write a second application (which we will soon).

So I gave him the go ahead to rewrite the interface. He spent the day writing it anew along REST principles. I haven’t reviewed it yet, but I’m sure its much better; also, having created it, he’ll be much more productive writing the client.

So why did I drag my feet? Because I believe in Doing It Right (or putting in significant effort to get it right) the Second Time. Not the first time, and not the third. In particular, for an interface, thinking hard about what the best abstractions are is best done in conjunction with writing the 2nd client. Its often worth *not* doing for the first client, even if this means parts will have to be rewritten.

This isn’t a hard rule (note that I caved to my developer rather than argue). Also, for tasks you have already done before and know how to do, by all means do them right. But for new, exploratory work, it is nevertheless a good tenet. The intuition is the same as for pairwise testing and binocular vision. To tell the difference between phenomena and epi-phenomena often requires more than one perspective; much more rarely, for the main outlines at least, does it require more than two.