Month: March 2011

Darwin and the theory of software evolution

Posted on by will
Bower bird

Female bower birds prefer males with colourful blue tail feathers and an impressive nest filled with lots of blue ornaments. To a bower bird, the brightness and quality of your tail, as well as your ability to gather a stunning assortment of blue nest decorations, indicates how healthy and strong you are, and how likely your genes are to produce equally strong and healthy offspring. In other words, a bigger tail and a cooler house equals more sex, which equals more children. Your genes live on.

Generation after generation the strongest genes survive, the weakest ones are killed off, and the species evolves – better and better. It’s survival of the fittest. Or, perhaps even more apt, survival of the most effective.

Good software product development tends to emulate Darwin’s evolution. Software is built, released, used and measured. The successful features, the heavily used features, the most often talked about features receive more development, more design, more attention; the least used are left alone, watered down or removed entirely. Survival of the most effective.

On the web we have the powerful ability to accelerate the evolution. We can release software updates multiple times per day. Design – code – release – measure – rinse. Repeat. Techniques such as A/B testing accelerate it even more: which is more effective? Text link or graphical link? Blue feathers or green feathers? Big nest or bigger nest? Survival of the most effective.

For the male bower bird, just as for software products, the audience (user) is critical. Every decision the bower bird makes will be judged by the female. It doesn’t matter if the nest is made of wire instead of twigs, or if the bower produced a new nest creation framework. The female bower doesn’t care; that’s not what she makes her decision based on.

Is your product evolving? Who is your audience, and who are you making your product decisions for? Are they the same?

The space between

Posted on by will

Web developers can tell you that application speed is all about latency. It’s about the speed between component A and B; the distance between this server and that one; the response time of that API. In other words, it’s about the space between.

In organisations complexity is compounded in the spaces between – the spaces between teams, between components and between divisions. The trouble is the spaces between are often a no-mans land that is no-one’s responsibility in particular… but it’s the spaces between that matter if you want to get anything meaningful done.

Factories build detailed processes to help their employees navigate the spaces between teams to get things done. But what if there is no process for what you need to do? What if there is no roadmap to tell you how to get there?

If you understand the spaces between, you don’t need a playbook or a manual. When you step in and own the space between, you can make things happen and get stuff done.

The spaces between are your opportunity to do something new and valuable.

The sign is not the solution to the problem

Posted on by will
The sign is not the solution to the problem

This sign reminds me of a presentation from Seth Godin at the 2006 Gel conference. This was one of his examples of stuff that is broken. “They’re building a device that can crush small children to death,” he says. “They oughta walk down the hall to the engineers and say, ‘The sign is not the solution to the problem‘.”

The sign, it turns out, is a workaround. It’s a hack. The real solution involves fixing the gate so it won’t mangle your hand or crush you to a pulp – but it takes someone to stand up and say “hey, guys, is this really the best we can do?” Even if it’s not her job to do so…

Another example: an internal team is delivering you an API that’s changing constantly. You find yourself rewriting large sections of code constantly to work around the changing API. What do you do? Do you happily (or unhappily) go on re-writing code every week when the API changes? Do you build an extra integration layer between your code and the API to manage the scope of the modifications you have to do? Or do you start a discussion with the team providing the API about why it is changing so often, and maybe implement an API contract between you and them?

Often, (every day), we see stuff that is complex, that is broken or that us just plain silly. When you encounter complexity or brokenness, I think you have three choices:

  1. You can accept the complexity or brokenness, and do nothing.
  2. You can accept the complexity or brokenness, and try to hack a workaround around it.
  3. You can ask, why is it complex? Why is it broken? And how can we fix it (properly)?

Doing #2 might help you navigate the problem, but it creates debt for you and your organisation that someone needssigh to repay some day.

Doing #1 is, I propose, at best depraved indifference; at worst malevolent and destructive.

Be like water

Posted on by will
Flowing water

I remember reading about a concept from Taoism called Wei Wu Wei. Roughly translated it means “action without action”, or “effortless action”. In the same way that running water naturally and effortlessly flows around obstacles, so should our actions be thoughtful and mindful, but effortless.

Bruce Lee, when describing his martial art Jeet Kune Do, said:

“Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way round or through it. If nothing within you stays rigid, outward things will disclose themselves.”

Software development process is like this: like water. The path from concept to released software is a flowing stream, and as product creators it is our responsibility to ensure that it can flow easily and effortlessly.

Your product development process can either help the stream flow, or it can create dams. A broken development server, for example, is a dam. A bureaucratic and document-heavy change management process is a dam. Dams create tension and confusion. Dams create waste.

Focus on avoiding wasteful process. Tear down dams.

Be like water.