The Slow Food movement promotes an alternative view of the preparation and consumption of food. In their eyes fast food is the inevitable outcome of an approach to life in which people can be treated as machines and ceaseless haste has become a virtue: "We are enslaved by speed and have all succumbed to the same insidious virus: Fast Life, which disrupts our habits, pervades the privacy of our homes and forces us to eat Fast Foods."
The movement's emblem is a snail, appropriately enough: the Snail is "of slow motion, to educate us that being fast makes man inconsiderate and foolish"; since it carries its house, "wherever the Snail is, that is its home". I think that the message here is applicable beyond just food: consider for example the differences between "fast software" and "slow software"*.
Fast software is churned out for minimum cost by low-skilled staff that have few opportunities for growth or advancement. (The true cost of the production of the software is hidden from the consumer at the time of purchase.) The need for conformity to the fast software production process subsumes the individual needs or talents of the staff, and requires that different products have similar "ingredients" (tools, languages, architectures) and hence similar "taste" (user experience, fit to business need). The quality of fast software is uniformly low but the brand power of the producers maintains aggregate consumption levels. Consuming fast software brings little sense of satisfaction but it requires little effort and you can rest assured your competitors are doing the same.
Slow software is crafted by skilled teams that come together to meet the particular needs of a single purchaser. Each slow software project evolves in its own way, and each member of a slow software team is expected to bring their unique skills to bear on the challenges faced by the team. Working on a slow software project provides opportunities for team members to both pass on and gain expertise. Slow software teams make careful tool and technology choices to suit their operating environment, and pay constant attention to the needs of their users and customers. Because slow software teams take pride in their work, slow software is of high internal and external quality, and slow software producers gain new business through recommendations by satisfied customers rather than through branding or advertising. Consumers of slow software engage with the producers during the production process, and although this requires time and resources it is a rewarding experience that provides a significant business advantage.
This contrast characterises what I see as some of the essential differences between the mass-market big-consultancy approach to business systems development (fast software) and a smaller scale alternative that emphasises craftmanship and diversity to the benefit of all parties (slow software). And perhaps the pursuit of slow software is one way of satisfying the principles behind the Agile Manifesto?
* In 1607 Francesco Angelita wrote a book about snails in which he said that humans had much to learn from them: Slowness was an essential virtue, as was adaptability and the ability to settle anywhere, in any situation. By slowness, he meant both prudence and solemnity, the wit of the philosopher and the moderation of the authoritative governor. We could extend this interpretation to say that the snail takes its time as it trails along, impervious to haste and readily at home everywhere.
Postscript: Bob Martin covered much the same ground earlier this year: You don't have time not to do it right! Where did we get the idea that our companies wanted us to write crap? Aren't they paying a lot of money for this software? Aren't they going to depend upon this software for profits? Isn't this software worth a lot? If so, then why would our company want to pay for crap that slows us down? Wouldn't they rather have good clean code that keeps us running fast?... Remember, two years from now all people will see is the mess, they won't see how fast you got it done. Nobody remembers the speed, they only remember the mess. So do it right... Take my advice: go well, not fast. Care about your code. Take the time to do things right. In software, slow and steady wins the race; and speed kills.