Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Monday May 03, 2010
09:08 PM

Frugal Innovation - The Economist discovers ::Tiny

[ #40343 ]

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/~r/economist/audio_all/~3/e078AnUezYE/20100416_sr_in novations_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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Joel "The Joel" Spolsky advises against such 80/20 behavior.

    You and your experience with successful ::Tiny projects are cast into oblivion, never to be discussed again as a viable solution to many problems!!

    • 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 wher

      • 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, wheth

  • These are the main ideas behind WebNano [github.com]. You are now doing that web frameworks review. WebNano is still nothing more than a proof of concept and I know that you probably don't have time to have a look at each of the dozens of recent Perl web frameworks - but maybe you'll find it interesting to try one that is less than 200 lines. It implements the simple web request path to library name dispatching in a way that is easy to override and extend on per directory basis. I'll appreciate any comments.