All the Perl that's Practical to Extract and Report
use Perl Log In
Alias (5735)
Frugal Innovation - The Economist discovers ::Tiny
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
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
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_i
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.
help them think they understand.
--Larry Wall
Obligatory FAIL... (Score:1)
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!!
Re: (Score:2)
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
Re: (Score:1)
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
WebNano (Score:1)