The Second Client Effect

I could have sworn there was an established name for this, but nobody I’ve asked can come up with an example, and my question on programmers.se got downvotes and close votes within an hour, so I guess I’ll just name it myself 🙂

We try to design sometimes for pluggability, and for the general case. We sit and we diagram and we think about broad use cases. And we’re often very wrong; that’s why YAGNI exists. So we sit down and we implement a single client, a single plugin as an example of our pluggable architecture, a single database provider. We deploy to a single platform, with a single distro of linux or version of Windows, maybe behind nginx or Apache but not both.

And it works great. We test it, the design seems solid, we’re all excited about how cross-platform or pluggable or multiple-client-friendly this system is. We pat ourselves on the back and congratulate ourselves on a job well done. Mission Accomplished!

And then we write the second client.

That bit where we were so proud of using generic terms actually doesn’t apply at all. We remembered about the different slash types but not the case folding. We didn’t realize SQL Server couldn’t do that, seriously, it’s been in PostGreSQL for years. We never thought about spaces in commands or what if the forum we’re integrating against doesn’t have chats at all or what happens if you don’t have Ruby installed on your system.

That second thing, whatever it is, opens brand new doors for us. We learn things we never expected about our API design, about our coupling, about our philosophy overall. If our architecture doesn’t need to be torn down and rebuilt from scratch, we feel an exhausted sense of accomplishment: we survived. We may be battered and bruised, and our application may feel like it’s being held together with duct tape and twine, but we’ve turned a real corner now. The third thing will be easier, and the fourth, and the fifth, and maybe by the time we have ten things we stop caring about the things and let other people do as they please without needing support from us every time.

There’s a long standing saying that two is an impossible number: you can have exactly one thing, or you can have infinitely many things, and you should plan accordingly. Even when you plan for infinitely many, however, two is an important impossible number. It takes two to tango, but it’s impossible to be of two minds at once and serve both masters equally well. There’s always that friction, that hurdle you have to jump when you encounter the second client.

Anyway, like I said, I couldn’t find this named anywhere, so I figured I’d better write it up myself.