The Meme Lifecycle

This article is in two parts.  Below is an interview/discussion between Chris Matts and Julian Everett introducing the idea of memes and what they mean in the software world.  This is followed by a comic that delves in deeply into how memes can be used to better understand the business environment and how to make better decisions based on that knowledge:

Chris Matts (CM): So, what do you think of the comic strip then?

Julian Everett (JE): I'm deeply honoured to be appearing in it - thanks very much. And nice media specs! My current client will be most pleased.

CM: Do you think it's a fair representation?

JE: Well firstly I should emphasise that it was Dawkins, Daniel Dennett and others who mapped the full gene concept to memes. All I have done is start thinking about software product development in terms of memes, and programme management as being foremost a speculative investment activity.

CM: Which means what?

JE: Well an IT business case can be viewed as a meme - one that is competing in the complex ecosystem that constitutes a market sector. The extended phenotype of that meme includes unit tests, application code, the project team, stakeholders, operational and training infrastructure, marketing campaigns and anything else in which investment is made and that affects the fitness and profitability of the business case.

CM: What are the implications of this in practice?

JE: Firstly, we know from complexity science that the connections and interdependencies in complex systems makes their behaviour much less predictable than simple physical systems. An obvious example of this is capital markets. Once we realise the environment in which we are launching a product is intrinsically unpredictable, then it fundamentally changes our approach to managing technology investment. This means taking the iterative, adaptive principles that have already proved themselves for managing complexity in software, and scaling them out across the whole business value stream. The result is a move towards a "test and learn" product development culture, incremental funding models, minimising amortisation periods and limiting liability - where by liability I mean spend on all development work that has yet to ship - and wherever possible incurring costs just-in-time at the point of revenue generation.

CM: This sounds like it would solve a number of problems.

JE: Indeed. Fundamental to this is the notion of failure containment. Once you realise that a system is unpredictable, you have to treat failure containment and exception handling as a first order design concern to borrow Michael Feathers' excellent phrase [http://www.agile2009.org/node/1953]. We recognise the importance of this as applied to software design, but what about programme management methodologies for example? How many of them treat project failure as an integral part of normal business operations, something that inevitably results from market uncertainty? Most organisations today aspire to a zero project failure rate for technology delivery but I think that is the wrong approach.

CM: How would you treat project failure?

JE: I think we should be performing regular culls to kill off the zombie memes in our project population (which drain the staffing, morale and financial lifeblood of an organisation in a very real, painful way) in order to keep the population as a whole healthy. From this point of view, project success is a question of mapping as closely as possible to the actual useful, profitable lifespan of a business idea rather than being anything directly related to on time, on budget. That's not to say that I think failure is in any way somehow good or acceptable...

CM: Or that all failure is due to market uncertainty?

JE: Absolutely, far from it. I would make a key distinction between a.) accidentally flawed business cases, where code quality issues, lack of test coverage, chaotic delivery processes and similar can all put paid to what should clearly be a viable business proposal, and b.) intrinsically flawed business cases where market changes turn what was a good idea into what is now a bad idea. And this highlights the critical importance of high quality, predictable software delivery processes. The only way we can manage uncertainty is by reducing the variables. Chaotic project practices generate vast amounts of accidental complexity noise, which makes it almost impossible to identify that subset of business cases which are actually intrinsically flawed. In other words, the way to generate the most profit from technology investment is by top quality development and delivery practices, which ensure the success of intrinsically viable business cases and which enable the fail-early, fail-fast identification of intrinsically flawed ideas.

CM: How does this approach work with an organisation's long term strategy?

JE: A long term commercial vision is obviously critical for every organisation. At the same time, the reality is that markets are intrinsically unpredictable: no management theory or strategy methodology is going to alter that fact. This leaves us with two options. Either we can ignore reality and continue formulating five year plans that never get reviewed or else we can adopt an evolutionary approach, where the additional sources of information created by ongoing, incremental delivery are used to refine and adapt our strategic planning on an ongoing basis to ensure it is always as effective and relevant as possible.

CM: That sounds like it might be helpful to think about in terms of a captain instructing adjustments to his ship's course in response to regular feedback from the crow's nest?

JE: Exactly! In fact I reckon that would make a great cartoon: "Agile Pirates of the Caribbean"!

CM: I know you are very interested in real options. Can you tell me how they fit into this picture?

JE: Essentially I use real options as a meme expression control mechanism. Estimates of value, cost and risk are used to approximate the optimal exercise point for an option, where the underlying asset is the meme phenotype, for example the featureset or marketing campaign to be implemented. That, as opposed to project prioritisation - which is really an implicit kind of valuation anyway - determines what gets built and when.

CM: Finally, in the comic did I get everything right?!

JE: The only minor point I would make is with reference to page three: I think of the extended phenotype of a meme as static rather than context dependent. The appearance of context dependency is created because the context selects for relevance. In other words I think there are two meme variations with static phenotypes rather than one meme with two context dependent variations. Apart from that, it is great.

About the Authors

Julian Everett is a freelance architect with thirteen years development and design experience working on projects for media and financial services organisations. He is particularly interested in the use of real options to inform prioritization and architectural decision-making, and the application of ideas from evolutionary theory to software product development. For the last two and a half years he has been working for BBC Worldwide.

Chris Matts has worked in Investment Banking since 1993, mostly working on trading and risk management systems. He has performed a number of roles including developer, business analyst, project manager and "pointy haired management". He became involved with Agile / Lean in either 2002 / 2003 (He cannot remember to be honest). He did a Masters degree in "Risk and Optionsy" maths stuff a long time ago. He looks forward to the day when he can give it all up and co-produce the movie adaptation of the real option graphic novel with Frank Miller. He thinks everyone should read "Understanding Comics" by Scott McCloud.