Jan 29

Anybody here ever seen a zombie flick? Well then, we all know what a zombie is, but what is a zombie meme? Read on for more.

What is a meme?

For that we need to refer to Richard Dawkins and his book The Selfish Gene. He makes the parallel between a human gene and a unit of culture, which he termed a meme. I’m using culture here in it’s social sense to mean a collection of ideas that shapes our actions that is common to our society. There are a lot of interesting parallels that cross over between the genome based view of biological systems, and the memetic view of cultural systems.

For example, our genes use us to replicate. Therefore genes compete with other genes (in other humans) to ensure their continued replication. One strategy is to introduce characteristics in their host that promote the end result of successful replication. This is the basis of evolution and the continued survival of the most fit organism for their environment.

Memes compete with each other by taking up space in our culture, which essentially means our awareness. They can be as simple as knowing that an iPod can be used to play music, or as complex as a natural language. To be successful a meme must replicate, and there are many strategies to help it do so. The “put wheels on a sledge to make a wagon” meme was successful in creating the automobile industry because it was immediately obvious to anyone looking at a wagon how to build it. The manifestation of the meme (the wagon) was replicated, and so the meme was able to leverage this to create many more copies of itself than the original item. More people know about wagons than own one.

So a zombie meme is…?

One that no longer serves a useful purpose and is simply getting replicated for the sake of it. People simply adopt the zombie meme as “best practice” without question and mindlessly repeat the instructions regardless of how damaging those instructions are.

Examples of this include wasteful business practices:

“Can you print that email for my records?”
“We only take orders by fax, then we type them into our computer system. Hope you’ve got good handwriting.”
“Please read the 50 page guide before filling out this form.”

or software development methodologies:

“Code around it quick, we’ll get the users to test it.”
“We design, code, test and ship. In that order. Once.”
“We don’t use XP, we use Scrum.”

Hang on – did you just have a go at Scrum?

Indirectly, yes. Scrum is the prevailing Agile implementation and there are a lot of excellent reasons to use it. However, simply using a particular methodology without fully understanding what type of development environment it is targeted at is essentially allowing a zombie meme to infiltrate and replicate.

But everyone does Scrum so it must be the best, I hear you mutter. Not necessarily. Consider the article Flaccid Scrum by Martin Fowler where excited project managers pick up on the Scrum process. All is well for a while then the project slams into a brick wall due to overwhelming technical difficulties caused by a legacy code base. This isn’t Scrum’s fault, you need to have good technical practices in place before Scrum will show it’s many advantages. A better choice in this scenario would be XP with all it’s technical recommendations.

Another scenario is that the nature of the work doesn’t lend itself to a constantly changing work load, such as maintenance programming or rapid response to a fickle client. Some changes take a day, others a week or so. Scrum relies on a clear stretch of time to accomplish the work, whereas Kanban provides a much more flexible approach.

And what if the project involves a dual-shore development team, operating in different time zones? It may be better to adopt the Stride approach (PDF), which is based on Scrum but tailored for separated teams.

As I mentioned earlier, memes replicate, but they also mutate leading to a conflation of ideas that can in turn lead to a better fit. Such is the case with a group of people who are now trying to blend Scrum with Kanban to find an even more efficient and flexible development process.

There are interesting times ahead, and not a zombie in sight.

Share
Tagged with:
Jan 09

How to be Agile when all around you are not – part 1

Many people have heard of the Agile development methodology but how, exactly, can you introduce it into your own workplace? This series of articles aims to provide you with a simple set of instructions that you can implement in virtually any language to make your own day to day development as productive as you can. This series is aimed at developers.

I’m assuming that you’re at the position where you’ve heard of Agile development and read some hype about extreme programmers cranking out huge systems in the blink of an eye. While this is great to enthuse people about the benefits that Agile development can bring, it does little to answer the question of how. Hence this series of articles. I aim to explain how to change your current mindset to one that embraces Agile thinking and to bring that thinking into your organisation little by little through a series of positive changes that reap instant rewards. Note that Agile is not a process, it is a mindset.

One final thing, my specialist subject is Java so I will tend to use Java based examples, but the principles that I’m working to are applicable to almost any language.

Let’s get started.

First and foremost you must work to reduce complexity. Complexity takes many forms, as anyone who has worked with any large system can testify. Often it seems that in order get anything done it is necessary to edit about 10 files, each of which is scattered about over 3 projects and involves 6 people to sign off at every stage. While this appears to introduce safety, most of the time it just makes extra work for the sake of it.

Just to be clear, I agree that in safety critical environments it’s necessary to be very careful about what changes are made to an existing codebase – nobody wants buggy code in their heart monitor after all. However, for most projects a pair of developers who are well-versed with the code should be able to decide between themselves whether or not a particular change is going to cause problems. If they’re not sure then a quick phone call to the relevant authority should be able to resolve any issue.

The quickest and easiest way of reducing complexity is to apply the DRY principle, that is, Don’t Repeat Yourself. There should be a single point of reference for any piece of data within the system, and the mechanism for retrieving it should be simple, very well defined and consistent.

This doesn’t mean use the same system for everything – that way lies madness. Rather, consider what the data is about and provide a suitable mechanism from there. So, what data am I talking about here? Everything is the quick answer, but really it’s all the creative work associated with the system, not just those system configuration parameters that I bet you were thinking about. This list includes supporting documentation, source code, schema scripts, build and deployment scripts, system parameters, system data, site content (images, videos, music et cetera) and everything else that requires a human being to create.

While this may seem daunting at first, tackling each part at a time leads naturally to an extremely efficient development process that is very responsive to changing requirements and is sufficiently robust that failures are caught very early on.

As you may have guessed, the DRY principle can be thought of as the central theme that underpins all of the other Agile practices (which I’ll introduce in later articles so as not to overwhelm you at the start). Once you start looking at all the processes that support the development of your system through the DRY lens you’ll notice a lot of inefficiency which can be pared away.

In part 2 I look in detail at how to apply the DRY principle to the issue of day to day coding since for most developers it is what they have the most control over.

Share
Tagged with:

You should follow me on TwitterYou should follow me on Twiiter here.

preload preload preload