index.md 9.1KB
title: Meditation Driven Development
url: http://www.ckwop.me.uk/Meditation-driven-development.html
hash_url: 28d1831eda
<img src="http://www.ckwop.me.uk/images/Meditation.jpg" alt="A silhouette of a person meditating."/>
In the beginning
Tim is a veteran programmer. He works at a world renowned software company. Despite this, in his long career he has seen many projects fail
and only a few succeed. After 15 years developing software, he decides he wants to get out of the trenches and start managing projects.
He's tired of seeing projects fail for entirely preventable reasons. He realises that the only way to fix these things is to be the
guy who makes the decisions on these wayward projects.
Tim, like most developers, is quite a eccentric man. He is an open source enthusiast and he has written a great variety of open-source software. Before writing any code on his projects, he usually spends an hour doing yoga followed by intense meditation. After doing his meditation he finds that he writes cleaner, better designed code.
One day, he is meditating when it strikes him: "Maybe this is the solution to the software crisis, everyone needs to meditate before they write a line of code." Meditation Driven Development (MDD) was born.
Tim goes to work and tells his team about his new methodology. Being good friends of Tim they decide to give it a try! Tim waits patiently for a project that he can try it out on.
The first project
It's day one of the implementation phase of the project. Tim rides his bicycle to work with extra-gumption. "Today will be the start of something great," he says to himself.
It's 9 AM and it's time of the first team meeting. Tim asks everyone to sit around on the floor in a circle and reflect deeply on a particular passage from the Bible. At first, his team are uncomfortable. They're unsure of what to do, but under Tim's careful direction he manages to get a result. His team manages a 45 minute meditation and afterwards they're energized and ready to write great code.
Tim mandates that all the team members must meditate twice a day, once when they come to work and once when they return from lunch. Each meditation session will be no shorter than 45 minutes long. This will be done without fail, every single day of the project.
The project was scheduled to last three months but Tim's team was done two weeks early. Not only that, his team's software contained 20% fewer bugs than the company average. Tim concluded that MDD must have been responsible. "MDD WORKS," Tim exclaimed!
Spreading the gospel
Given his early successes, Tim decides to roll out MDD across all his projects. His early successes were repeated. His boss is impressed and asks why he thinks his projects are enjoying so much success. For Tim, the answer is obvious: "MDD. MDD allows us to produce higher quality software, to budget, on time."
Tim convinces his boss that the whole company should use MDD. Tim sends out his disciples to other teams to convert them to MDD. Slowly but surely his company converts to MDD.
Tim realises that other people could benefit from MDD, so he makes a deal with O'Reilly and writes his transformational book, "Meditation Driven Development - The way to cheaper, more reliable software."
The initial reaction is positive. Before long, a line of people are queueing up at Tim's door to get in on on the new MDD craze sweeping the industry.
The MDD Manifesto
A year or two after Tim's book on MDD, it was clear that MDD was being misapplied in some companies. Some teams were having trouble making MDD work in their company. Some people were not following the strictures of the book correctly.
They were having 20 minute meditations instead of the mandated minimum of 45 and they were only having one of these per day! Tim exclaimed, "How could they possibly expect the methodology to work when they're only doing one meditation per day!?" Something needed to be done.
By this point MDD had fractured in to a series of closely related but slightly different methodologies. Some preferred to meditate to music, other liked to meditate on the words of famous poems. Others preferred four shorter sessions per day instead of the original two. The differences mattered less than the similarities. As long as there was an hour and a half of meditation per day, every day, it was MDD.
Tim and his disciples sat down and bashed out a manifesto that bound these various strains of MDD under a common political philosophy. They vowed to take forth the central message of MDD and transform the industry.
MDD becomes mainstream
It's now nearly a decade after Tim wrote his transformational book. Once a year he keynotes at "MDD-con" in San Diego. He has released a series of books on the subject and makes a substantial amount of money in consulting on everything and anything related to MDD.
MDD is now an established cottage-industry with a series of satellite conferences spanning the globe. It's now so popular that even the pointiest of pointy-haired bosses is starting to hear about it.
Yet, all is not well in the MDD community. Ordinary companies are having real trouble getting the benefits of MDD. Projects are still late, expensive and buggy. Tim's career has become a continual fire-fight. His consultancy gigs are no longer about getting people to adopt MDD but are about fixing problems in projects that already use MDD!
MDD fifteen years on
It is now over fifteen years since Tim wrote his award winning book. MDD is now thoroughly mainstream and used by a huge variety of teams. Despite Tim's initial success, MDD projects on average tend to be late, over-budget and low quality.
Tim still extols the merits of MDD but he finds dissatisfaction wherever he goes. A whole generation of programmers has now grown up with MDD and they're disillusioned by failed project after failed project. Tim can't understand why people were having such a bad time with MDD. He just knows that MDD works! He's seen it with his own eyes! In his own mind, he concludes that the problem must be that nobody is doing it right!
One day, Tim comes across a team led by a bright-eyed manager called Cathy. Cathy's projects are on time, to budget and much less buggy than the company average. Cathy was a developer for fifteen years and has only recently become a manager. Tim is suitably impressed by her success, he asks her what her secret is:
"It's our new methodology, QDD. QDD allows us to produce higher quality software, to budget, on time. It's going to transform our industry."
Afterword
Why did MDD work at first and then fail when it became mainstream? The reason that MDD worked initially had nothing to do with strictures of MDD. Tim was a talented developer working in a company filled with talented developers. Pretty much any methodology you care to think of was going to work with these people.
Moreover, Tim's initial team were the earliest of early adopters hand-picked by Tim himself. They were the very people that would develop high quality software naturally anyway. The only role the MDD had was in helping the team to gel, and once they had they looked like an impossibly productive team. Tim misidentified the source of this productivity as being the result of his methodology, rather than his competence of himself and his team.
As MDD became more widely used, the average quality of the developers using the methodology dropped and so did the success rate of using MDD. By the time it was used by the average team, MDD got average results.
I'll close with a quote from one of the greats of our field, Robert Glass:
People matter in building software. That's the message of this particular fact. Tools matter. Techniques also matter. Process, yet again, matters. But head and shoulders above all those other things that matter are people.
This message is as old as the software field itself. It has emerged from, and appears in, so many software research studies and position papers over the years that, by now, it should be one of the most important software "eternal truths." Yet we in the software field keep forgetting it. We advocate process as the be-all and end-all of software development. We promote tools as breakthroughs in our ability to create software. We aggregate miscellaneous collections of techniques, call that aggregate a methodology, and insist that thousands of programmers read about it, take classes in it, have their noses rubbed in it through drill and practice, and then employ it on high-profile projects. All in the name of tools/techniques/process over people.
Don't fall in to Tim's trap. Great developers create great software not because they follow the strictures of some methodology but because they are truly great, gifted artisans.