jonsteinberg:

People on the business side of internet software, constantly bemoan their inability to code.  I’ve been guilty at times of the frequent refrain, “My kingdom for the ability to code.”  However, I’ve found over the past year that the emergence of APIs coupled with eLance (or oDesk or one of the other contractor platforms) have made this expression of exasperation largely hot air.

For $500 and four weeks of late night emails to eLance developers, you can basically spec and build simple, rough apps that knit or build upon open APIs to create things that are interesting and potentially valuable.  To be clear, you can’t build complicated apps or the next Salesforce.com on this kind of shoestring, but you can achieve the kind of learning, vetting, and experimentation that is left undone if you don’t.

I call this process Hackable Business Development.  If you’re interested in a platform or service from an intellectual, career, or partnership prospective, you simply must build on it.  APIs are such a vital part of web business growth and extension, that the API is almost more important than the front-end.  So if you are really interested in a web site, the only way to understand its functionality and potential is to hack on its API.  An API is in many ways the equivalent of a living breathing business plan  - replete with the company’s view of its place in a highly competitive, fragmented world of web services.

I consider this the modern day equivalent of reading up on a business and sketching out your thoughts.

When I was interviewing to work at Majestic Research in 2003, I was asked to write up a few pages of ideas to grow the business.  I did this, but I’m fond of saying “ideas are like water”; they’re everywhere and they flow.  How much more impressive and educational would it have been for me to get a raw feed of API data from Majestic and model it.  I hadn’t yet discovered the Hacking Business Development model, and I was lucky enough to get the job at Majestic, but it would have been so much more valuable for me to have hacked for them.

API documentation is basically written in prose, so that’s always a good place to start.  Instead of taking a novel to bed tonight, take some API documentation.

Interesting ideas. I think even engineers could start using oDesk. I’ve written enough twitter apps to know a framework others should work in. It would make their job easy, and save me time.

I think it was Fake from Flickr who said APIs are “Biz Dev 2.0”. It’s so awesome.

Having _made_ one for Tipjoy, my take aways are basically that you should make an API first - then build your service on top of it. Eat your own dog food. Also, there is a good argument that if you make good coverage in your API, your data representation will be better.

People don’t talk about this specific issue a lot - but they do talk about it indirectly. When a company needs to do a redesign, the representation of the data is what matters most. If you change the data, you need to evolve what is already there, and swap out the new framework quickly. Also, the speed at which you build new tools is almost always related to the quality of your data representation. If you’ve built something good, new tools can build on top of it with little friction from data representation evolution.