I was at the SF MoMA this past weekend - and if you’ve ever been, you’ll (hopefully) know that in their standing collection is a set of art from a number of particularly interesting artists, one of whom (Duchamp) is known best for a work photographed here. This is Fountain:

It’s a urinal. It’s a run-of-the-mill, yes-he-really-did, urinal. Made into art (and thus deserving of a spot inside the MoMA) simply by declaring it as such.

Of course, some amount of reputation was required to pull that off, and some other, more traditionally respectable work had to be done to acquire said reputation, but in the end - he’s able to pull something someone else technically “made,” and enhance it for his own purposes.

In the software world, there are those who seem to find it unthinkable to use off-the-shelf products to help with the engineering process in-house. While this attitude has certainly led to plenty of innovation (thank you for Cassandra, BigTable, etc), these special cases seem to really only be the extreme of the “there’s nothing out there just for us” attitude. And, I suppose, to play devil’s advocate, in their situation, off-the-shelf tools probably aren’t quite right for their incredibly unique case. (Or maybe they just had too many engineers and not enough game-changing projects?)

In any case. One of the things I’m getting used to at Aardvark - and starting to really appreciate the wisdom of - is utilizing existing and established solutions when necessary. We need bug/ticket tracking? There’re tons of solutions out there - done! Better log analysis? Found, installed, done. System and cluster monitoring? Perhaps not entirely ideal, but good enough - done. It lets the team know what we need to know, and gets us free to focus on what we really need to get done - the core product and infrastructure.

I joined a conversation this past weekend with a couple of people just starting to get their startup off the ground, and they were embroiled in a CouchDB vs MySQL debate - are relational databases really outdated, or are document-based databases just overhyped? Which is the better to start with for their startup? My answer - whichever makes your actual job easier. There are lots of cool toys out there, but there’s a careful risk vs. reward tradeoff you have to make - and when you’re focused on startups, can you really afford an awkward risk down the line with your data or architecture?

I suppose this is a long, elaborate rephrasing of “Worse is Better.” Take shortcuts and the quick, easy, established route to change the world, first - then figure out how to make it happen better.

Let me know what you think on Twitter.