In the April 15th edition of The Economist, they provide a special report on innovation in emerging markets.
http://www.economist.com/specialreports/displaystory.cfm?story_id=15879359
Half of the report focuses on what is essentially a restatement of the principles behind ::Tiny, but for real world products rather than software.
They term this "Frugal Innovation", and it involves taking types of devices consumed by the rich world, and then reinventing the idea behind them to make entirely new and novel devices (NOT just simple copies) that achieve the same or most of the same effect but for much less.
They trumpet the same magic formula that ::Tiny uses, which is to provide a similar but effective function at a 90% reduction in cost, compared to existing products that have evolved via "Fat Innovation" (the typical rich world innovation which results in having new models every year, with more features and more complexity).
Frugal Innovation doesn't just involve reducing the input and overhead costs, but sometimes reinventing the process used to create the software. And ruthlessly stripping out anything that isn't universally necessary.
Some of the same principles are now also being applied to services, with one Indian medical centre setting up essentially a production line for heart operation, applying the same principles of specialisation and copious less skilled support services that created Ford's original production lines for products.
There's a great podcast from The Economist on the same topic here...
http://feedproxy.google.com/user/r/economist/audio_all/user/3/e078AnUezYE/20100416_sr_innovations_4EQO.mp3
One interesting side note is that for software this same principle appears to feed into the measure of long term evolution I've mentioned in a couple of my talks, which is "Information processed, per unit space, per time".
This might be something that's actually interesting to measure in it's own right. You could measure this "Software Density" score by taking the amount of work some code does, and then look at how much code is never (or rarely) run.
This would be something similar to coverage testing, but for regular operation.
Joel "The Joel" Spolsky advises against such 80/20 behavior.
You and your experience with successful
Re:Obligatory FAIL...
Alias on 2010-05-04T07:08:40
I suspect that the key to
::Tiny is two-fold. Firstly it has to be 90% cheaper, or at least "transformatively cheaper".
Secondly that it should really supplement the more expensive solutions, not be a replacement or a leader into a new area.
If you try to write a
::Tiny module while also breaking new ground, the exploration process itself will drive you towards bloat. Because you have a monopoly on the area at that point, you have to serve everybody. It is only once a field is well understood that you know where the core of the demand is. You can focus on the most important area, while turning away people that need the additional features and sending them to the more expensive and complete alternative.
The Tata Nano might be cute, but clearly it's not going to be enough to drive around fat businessmen or store 3 kids worth of hockey equipment or camping gear.
Re:Obligatory FAIL...
xsawyerx on 2010-05-04T07:24:02
Agreed.
I still believe that while it's not a new-ground 80/20, it's still some type of 80/20, or even 90/10.
You still make the assumption that "after working with the technology for a while, we have a fair grasp of what core functionalities of it is really required and others can be supplemented much later or not at all" to make the
::Tiny module. So in the end - whether on new grounds or after extensively exploring an already existing ground - you make a distinction of certain features you care about, whether they were already implemented elsewhere or await your implementation.
Don't get me wrong - I think it's a good approach and has landed some great successes in various places (YAML::Tiny, Time::Tiny, Template::Tiny, etc.). I was just poking fun at the obvious "you should always provide 100% of the features" cult - which would condemn both 80/20 behavior on new projects and on
::Tiny'fied projects.
