|
||||||
| Few Interesting Observations on ‘The Evolution of Useful Things’ | ||||||||
| ||||||||
| This web-page extracts few interesting parts from another webpage “The (Predictable) Evolution Of Useful Things” by Darrell Mann. ‘The Evolution of Useful Things’ by Professor Henry Petroski (Reference 1) is a fascinating historical account of the evolution of everyday objects. The book uses a number of richly detailed case studies - from cutlery to hamburger wrappers, and paper clips to telephones - to build up a general picture of why things evolve the way they do. | ||||||||
| The evolution of eating utensil Fork: | ||||||||
| One of the most interesting historical accounts in the book concerns the evolution of the eating implement we know as the fork. The fork story begins in the Middle Ages, when diners would usually be found eating with a pair of knives; one knife to do the cutting, and the other to take care of the holding of the food being cut. | ||||||||
| ||||||||
|
Figure#1: The evolution of eating utensil Fork | ||||||||
| This method of eating prevailed - in Europe at least - until around the 14th Century, when two-tined forks first appeared in large quantities at the dinner table. It is suggested that the evolution from pointed knife to two-pronged fork occurred because of the problems of holding food in place with a single pointed device where the food in question was largely free to rotate about the point and thus impeded the cutting action. | ||||||||
| Introduction of the second prong eliminated this rotation problem. The problem then, however, was that, although good for holding, the fork was of little use in carrying food from the plate to the mouth. And thus emerged three-tined forks, and, even better, by the early eighteenth Century, the four-tined fork we know today. | ||||||||
| ||||||||
|
Figure#2: Sample evolutionary paths/experiments of Fork | ||||||||
| The fork story further presents a number of interesting evolutionary paths of the Fork. The proliferation of designs illustrated in Figure#2. This indicates, Darwinian rules for evolution also applies to evolution of useful things as well - Survival of the fittest. | ||||||||
| Fasteners – Story of Zippers: | ||||||||
| Among a myriad other examples, the history of fasteners is another entertaining and instructive story told in Professor Petroski’s book. In the story, we watch as clothing fasteners evolve from pins and brooches to clips and buttons, hooks and eyes, and on through to the zip fastener. | ||||||||
| Zippers first appeared in the last century, but new variants are still being patented today - e.g. the 1998 patent illustrated in Figure#3. (This patent search may have done in 2000, so we don’t know any newer patent-filings on Zippers). | ||||||||
| ||||||||
|
Figure#3: Typical Zip Fastener - US Patent 5,791,023 | ||||||||
| Although traveled a long way along the evolution path, the zipper is still some way away from an ideal final form. The fact that we can still see ‘problems’ like poor water-proofing capability, cleaning difficulty, starting difficulty, tendency to snag and trap flesh or other clothing, etc, clearly suggests that the zipper - or its successor - still has a long way to travel before we will finally be satisfied. The book makes interesting point that even when it reaches its ideal form, there is always room for improvements. | ||||||||
| Evolutionary paths for Products such as Cars, which are built using CBE: | ||||||||
| The automobile (e.g. car) was designed well over a century ago. The design of automobile and its components have been continuously refined little by little by thousands of groups around the world. Even today many patents being filed on the improvements of each of the auto-components such as Gearbox, Spark plugs, corroborator, tires or break pads etc. | ||||||||
| Any product build by using CBE (component based engineering) is evolved by refining each of its components little by little. Each component evolves nearly independently. So evolution path of the product is accumulation of evolution paths of the components. The fact is that developers/product-users continue to find problems or shortcomings, ensures that each component (of software or physical product) would has a long way to travel before reaching its ideal final form (e.g. recall evolution of Zipper). | ||||||||
| Why car design/blue-print not degraded into big ball of mud or spaghetti code? But today life of small software application having just 2 components designed by group of 2 working closely at one location is forced to begin as spaghetti code? An example code structure of a 2-component GUI application is given below, which illustrates that even today's best software architecture forces the developers to create spaghetti code. | ||||||||
| An interesting quote from the paper ‘Big ball of Mud’: Even (software) systems with well-defined architectures are prone to structural erosion. The relentless onslaught of changing requirements that any successful system attracts can gradually undermine its structure. Systems that were once tidy become overgrown as PIECEMEAL GROWTH gradually allows elements of the system to sprawl in an uncontrolled fashion. | ||||||||
| Note: We believe most of the products or components unlikely to reach ideal final form, since even when the product (or any one of its components) reaches its ideal form, many of us believe that - Still there will be always room for improvements. | ||||||||
| Today software designers/developers are often pressured to come up with perfect design first time, under the following conditions: In the beginning both users and domain-experts know very little about what exactly they need in the product (and often the domain-experts have little knowledge on limitations or strengths of software). Then the needs are poorly communicated to software designers and/or poorly understood by the software designers. The reality is they cannot come up with even a satisfactory design, until they built the product and they see how users are using it. The catch 22: They need experience to come up with a satisfactory design. How can they gain experience without a product and getting feedback from its real users? | ||||||||
| Almost every successful system attracts competition. More success means more competition. The competitors have a luxury to use the product and talk to its users. Hence they can avoid many costly mistakes, which are inevitable for the team that built it based on the imagination of a visionary or inventor. The new entrants don’t need to incur huge costs of educating the market about the utility of the new product. The new entrants have other advantages such as they could use the latest technologies, tools and know-how, as all are being advanced constantly in today's emerging net centric world. | ||||||||
| To stay ahead of the competition, any product must be designed to be highly agile. How long can any incumbent stay in business, if a new competitor is 3 times more agile (i.e. 3-time more agile means, it costs one-third and takes one-third time to make any large change or feature addition). Hence competitors’ products evolve many times faster than the incumbent’s product (which educated and established the market). | ||||||||
| Unfortunately any successful software product often attracts large deep-pocketed competitors such as Microsoft, IBM, Google, Apple or Oracle. In today’s competitive world, architecture of almost all successful products end up as Big ball of Mud, because they cannot refactor whenever they add a small change to add a new feature. Although no one admits to it, every one will be forced to make quick fixes. | ||||||||
| Charles Darwin Observed centuries ago: “It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change”. This also applies to both software and physical products. Which successful software or physical product (car, computer) in the world stop evolving after the first release? Notice the rapid evolution of products such as Web-Browsers or Spread-sheets (e.g. Excel or Lotus123). | ||||||||
| About 80% of software engineering deals with changing existing software (So does most physical products such as Cars or Computers). Systems must be built to facilitate change. Faster time to market offers huge competitive advantage. For example, incorporating successful innovations such as adopting new technologies, incorporating new features/requests and easy removal, addition of functionality. | ||||||||
| Any software designed as an ideal CBD-structure, will be 5 to 9 times more agile, than a software built using today’s best software architecture. One can find proof in physical products (e.g. cars, computers), most of which satisfy the 3 CBE-rules. | ||||||||
| The erosion of design structure can be prevented, if build to satisfy the CBD-structure. Any successful system attracts relentless onslaught of new needs that force piecemeal changes to code, which gradually undermines initial design structure or assumptions. Another example: True software components/CBSD can offer comparable or even better division of labor than the introduction of interchangeable components or Ford’s moving assembly line (hence can secure comparable productivity gains). | ||||||||
|
||||||||
