5 ms·
I don't believe this theory of 'build what had previously not been possible' because it is not true and does not match evidence. An example is the readiness of
by bl4k 16y ago
I don't believe this theory of 'build what had previously not been possible' because it is not true and does not match evidence.
An example is the readiness of markets. Many successful web 2.0 companies were re-implementations of old dot-com ideas, with the technology being the same (bar frameworks that minimized development time) but with a more ready user market and refined implementations.
For example: XDrive - Dropbox, Friendster, theGlobe.com etc. - Facebook, Yahoo bookmarks - delicious, boo.com - etsy, etc., webvan - amazon delivery, etc. etc.
Further, many of the technologies cited are old (GPS is almost 40 years old). It is economies of scale that resulting from market acceptance that make these technologies more viable. Most software products do not require bleeding edge technology, which is often a curse (ie. using HTML5 today when 80% of browsers do not support it).
If you think about what made YouTube, Facebook et al successful, it wasn't some magic new technology, it was the right implementation and market acceptance.
This bit has been done to death, but what is different today is:
* It is faster to develop apps because developer time is more efficient and scalable because of tools, but there is nothing in RoR, Django etc. that couldn't have been done 5 years ago with PHP (and I mean that in the end result, not how it is done).
* Broadband penetration (especially globally)
* Browser penetration (IE5 introduced xmlhttprequest in 98, but it took 7 years to reach a decent use base for Ajax apps to be viable)
If you went by the advice here and intoduced a bleeding-edge Ajax app that was bandwidth heave would have failed in 2000 (and they did, we would use xmlhttprequest for intranets only).
The risk with this advice is entrepreneurs betting on new over better and becoming complacent in believing that what they have as better and 'previously not possible' should win.
(edit: so I guess you could say 'build what had previously not gained market but would today because of tech penetration')
- chris123 16y agoI think all he meant you don't have to invent something brand new, but you said you should take advantage of the new tools, technologies, social graphs, etc. that were not previously available. It sounds obvious, and maybe it is, but it's a good reminder and he put together a great list with great examples. Hat tip / thank you to Jason.
- zwetan 16y ago> If you think about what made YouTube, Facebook et alsuccessful, > it wasn't some magic new technology, > it was the right implementation and market acceptance. I would have put that as the right implementation at the right time many implementations will fail simply because of being too much ahead of time the "right time" imho is not only about market acceptance or market penetration it's also about "when people are ready to accept it". Before google decided to use xmlhttprequest for gmail, nobody would want to use it because it was considered "IE only", but once google used it, it gave xmlhttprequest a certain credibility and then suddenly everyone started to use it and then the word "Ajax" was created. In another context, take smartphone publishing their location in foursquare or whatever, it's not only because they have the technology to do it (GPS), it's also related to social acceptance, after people got used to display their personnal infos on facebook, myspace, etc. then it is just a little jump to accept to display their geolocation. I do believe in "build what had previously not been possible" but it's not only because of technology or market penetration, there is also a big "social acceptance at the right time" parameter.
- jasonlbaptiste 16y agoYou could certainly build things that were possible before, but I'd rather suggest entrepreneurs go towards that, which wasn't. And if you do build something that was possible before, ie- Dropbox, then I suggest you use the building blocks to build an iteration that wasn't possible before. Dropbox was started as a small project by Drew and eventually a YC funded company with a small 25k in capital. It wouldn't have been possible to do Dropbox before AWS,etc. without spending a ton of up front Capex in hardware you may or may not use down the road.