Jonathan Tran wrote Stand on the Shoulders of Giants, an article arguing that software developers, and specifically web developers, should avoid replicating features available elsewhere. His argument is that we should build our applications on top of third-party services by the “giants” (e.g. Google, Yahoo) via their APIs instead of wasting time rewriting their functionality.

And he uses Instapaper, my read-stuff-later bookmarking tool, as an example of what not to do:

… the functionality of Instapaper is a proper subset of the functionality of del.icio.us. In other words, everything that Instapaper can do, del.icio.us can do and more.

Why then didn’t Marco build Instapaper over del.icio.us? It seems like a perfect match.

[…]

Instapaper’s value is solely in its amazingly simple interface. The reason I use it differently from del.icio.us is because its interface affords to different things. It makes different operations cheap, and that changes the way I think about those operations. But why doesn’t Instapaper integrate with my del.icio.us account, simply tagging things with a “read-later” tag? When it comes to bookmarking, del.icio.us is king; there’s no disputing that. Instapaper wouldn’t have less value if it were built on top of del.icio.us, it would actually have more.

For the sake of argument, I’ll assume that this is true, even though it isn’t, because Instapaper has features that Delicious doesn’t — and Jonathan seems to be severely underestimating the value of a good interface.

This isn’t a new argument — it’s the classic “build it vs. buy it” choice:

1. Reinvent everything yourself. This is usually chosen by those who don’t trust anyone else’s code, earning it the excellent nickname of “Not-Invented-Here Syndrome”.
   • Advantages: You own everything, you know how everything works, and you can modify everything to fit your needs.
   • Disadvantages: You must expend development time to build and maintain these components, and it’s easy to get distracted from your core competency with endless unnecessary projects because you won’t buy someone else’s bug tracker or invoice manager or shopping cart.
2. Use third-party software as often as possible.
   • Advantages: Third-party software can be more specialized to a narrow task, and it might be better than what you could build in-house. If it breaks, it’s not your problem. New features may be added with updates at no additional cost. You can stop worrying about lower-level problems and jump right into the interesting parts.
   • Disadvantages: Your ability to add or modify functionality is limited. If it breaks, you usually can’t fix it — you’re entirely dependent on the vendor. There’s no guarantee that the vendor will still exist to maintain the code in 6 months. And the vendor may decide to discontinue the product or change the pricing.

Like most religious programming arguments, there is no always-right answer: different situations justify different choices. But building Instapaper on Delicious would have been a terrible idea for many reasons.

Gains

Instapaper and Delicious do share some functionality: the storage and retrieval of a list of URLs. But that only took me a few hours to write. Nearly all other parts of the code (interface, user management, copywriting, etc.) took longer.

It would have taken me just as long to build an interface to the Delicious API than it took me to replicate all of the functionality I needed from it.

What would have been gained from that? Instead of maintaining the bookmark-storage code, I have to maintain Delicious API access. I’ve coded against a web-service API before, and good integration took a lot more work than I expected.

But there’s a significant cost to depending on someone else’s API.

Dependence

For one, not all of Instapaper’s users have Delicious accounts. For someone new to Instapaper, they would then need to confusingly sign up for two services. That’s enough of a barrier that most will say, “Never mind.”

And what about technical dependencies? If Delicious is slow or down, Instapaper would suffer or fail. Don’t assume that any service is invincible to downtime: a few months ago, Flickr was down for most of a weekend. And very few web-application APIs guarantee a level of service, so if I lost 8 hours of functionality and revenue from Instapaper because Deliicious was down, I’m out of luck.

There’s also no guarantee that an API will stay in its current state. What if the service discontinues the API because it’s too much of a maintenance or operational burden? Or what if they change the terms and it becomes unaffordable?

Competition

What’s the incentive for Delicious to even allow Instapaper to use it? While their functionality doesn’t entirely overlap, Instapaper is certainly a competitor. Why would Delicious willingly enable me to run a competing service on their infrastructure?

Innovation

Reinventing the wheel is often justifiable. If nobody had ever reinvented existing products, we wouldn’t have Google. Or the Playstation. Or nearly any Microsoft product.

Instapaper isn’t built on Delicious because it’s doing something different, despite sharing some underlying features. Sure, I could have built it on top of Delicious, the same way I could build a word processor with a set of macros for Microsoft Word, or Mozilla could have built Firefox as a GUI around the Internet Explorer rendering component, or Apple could have just abandoned Mac OS and made a pretty skin for Windows.

In each case, it just doesn’t make sense. The resulting products would suck and provide very little value.

If Instapaper were built on Delicious, it would be slow, complex, and confusing — it would lose all of the qualities that attract people to it. Instapaper has value not because of what it does, but how it does it.