software for sharing

As resources become ever more precious, efficiency becomes a matter of growing importance. My bet is that much of the 'growth' in coming years will come about through gains in efficiency.

One very potent way of using a resource more efficiently is through sharing.
However, not all things share equally well:

• sharing your shoes may not make much sense, while sharing a tuxedo is common (in the form of rentals);
  
• sharing your car with one person may be quite manageable, while sharing a pool of cars involves sophisticated logistics;
  
• some things worth sharing can age quickly, adding complexity to the situation (e.g. perishable food)
  

Sharing is easier said than done, but software can be of great help

• through facillitating the establishment of trust and accountability
  
• by taking care of logistics
• by allowing sharing to be driven from the grass-roots level, communities can function more autonomously and wean themselves off overly-centralised services and infrastructure

Sharing promotes a new wealth system, based on access, rather than ownership and control.

getting real

Getting Real is 37signals' (the creators of Rails) manifesto for designing, writing, maintaining and releasing software.

Many of us have begun to intuit this wisdom already, but even so, having these ideas clearly and concisely collected in an inspiring way can only be good for progress. I hope.

Here are a few of my favourite themes:

• Build less. Be ruthlessly minimalist about the scope of your software.
  
• In the interest of all your customers, you might have to say no to some of them. This is not a bad thing.
  
• Don't compete. Instead, play in the white space where the "competition" is limited to common-denominator, one-size-fits-all solutions.
  
• Embrace constraints, i.e. embrace reality. Say yes. Don't fret when reality unfolds out of line with expectations. employ reality as one of your staff members.
  
• Avoid indulging our collective preference-fetish. Don't defer decision-making to the customer unless you have a good reason to. Preference's can be a cop-out that adds noise to your app.
  
• Let the kitchen staff and waiters on your team reverse roles, to encourage a culture of empathy and to address the inevitable ignorance borne out of role-boundaries.
  
• Context over consistency: avoid rules and conventions for the sake of consistency. Do what makes sense in a given context, even if it compromises consistency.
  
• Don't under-estimate the effect of programming language and development tools on the software outcome.
  
• Forget about Functional Requirement Specs. They don't work and cause suffering. Stop the madness. (prototype instead)
  
• Open the development process to the public, warts and all. The future is transparent.
  
• Code is alive and can speak for itself. Listen to it. Software is more organism, less formal system. Treat it as such.
  
• Don't beta your software (to the public). It's like writing in pencil.
  
• Do what you love.
  

static vs dynamic worldviews

I especially like Ruby’s style, but any dynamic language will do for the purposes of this discussion. Dynamic languages started out side by side with static languages. But static dominated for various logistical and arbitrary reasons; and here we are, 50 years later, attaining Dynamic meta-magic again.

The beliefs underlying static languages are very reasonable. Here are a few that i have recognised:

• catching errors sooner is better
  
• to be more clear about the behaviour of software, you have to be more clear about types
  
• almost doesn’t count
  
• always expect the worst
  
• freedom is dangerous
  

But there is a new worldview that more and more of us are tuning into: all the ideas of Static-land are still considered reasonable from this perspective, but new interpretations become possible:

• catching errors sooner is great, but the price is often too high
  
• types are described on a higher level of abstraction: you care more about what the type can do than by what it is made of. Different things matter.
  
• almost is often good enough
  
• when we expect the worst, we focus on securing our position rather than on progress. But in return for letting go, a world of new possibilities opens. Expecting the worst brings about a situation which is better than worst, but not nearly as pleasant as it can be.
  
• freedom is a lot of responsibility