Fascinating parable about how "Software Movements" get started. Although, even if the initial effect observed is due to some sort of placebo effect, it might be worth it.
I didn't find it fascinating, but I think the point of the article wasn't that it's a placebo effect, but rather the meditation had nothing to do with it. The group was a hand-selected group of high-quality developers and they were going to do excellently with or without the meditation.
“Buddhism is an easily understood, energy-saving teaching; people strain themselves. Seeing them helpless, the ancients told people to try meditating quietly for a moment. These are good words, but later people did not understand the meaning of the ancients; they went off and sat like lumps with knitted brows and closed eyes, suppressing body and mind, waiting for enlightenment. How stupid! How foolish!”
I think you could find lots of interesting parallels between software development and religion. To a first approximation, it's all about old guys giving advice that's misunderstood and channeled into various schemes like consultancies and conferences and churches.
I only read the end of the article, but it seems the author agrees with you.
> 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.
But I think this concept of self knowledge is integral to Buddhism at the least, and I know understanding it can be part of swallowing an iron hot ball in zen.
Or an inherent failure of human communication. Previous generations can't communicate their own past point of view, experience and the meaning of the newly found solutions. The new generation try to interpret these solutions with their own point of view and lack of experience.
I agree with the general idea behind this article, which is : don't become religious about one method, one tool, one language...
However, the conclusion is really pessimistic !
"Great developers create great software not because they follow the strictures of some methodology but because they are truly great, gifted artisans."
So...non-gifted artisans will never produce great software ? We shouldn't try to increase the average quality of software by figuring out methods that work for the rest of us that are not "gifted" ?
So a buddhist monk walks up to a hotdog vendor and is asked what he wants to eat:
"Make me one with everything!" the Monk chuckles with a cheeky smile.
So the buddhist gets his hot dog and pays the hot dog vendor with a $20 bill. The vendor takes the money and expecting change the buddhist asks what is going on?
The smile is returned by the hotdog vendor; "Change must come from within".
Meditation does help in various aspects of life, including programming, but it disappoints me to see many people looking at meditation in a limited scope.
On the other hand, I realize that this is how many millions across the world get introduced and hopefully some of these millions will discover there is more.
While this has its points there is something missing.
Why were Tim's (and his group's) projects failing before they sdopted MDD? Were many of them new at the company? Did they have a bad manager that left as they started MDD?
If their new methology is bogus something else must have changed.
In the story as given, it says many of Tim's projects etc failed before they adopted MDD. What happened was Tim changed to being a manager (after 15 years dev experience) and formed a new team and adopted MDD. They then attributed to MDD the success, when in fact the success was due to people.
This point is emphasised again later when he finds a new team in his org when MDD is failing. That team has a new manager (with 15 years dev experience), working with a new team and a new methodology QDD. Again, the team attributes success to QDD, not the people.
ie the success is down to people, not the process.
If you realise MDD (and QDD) is completely made up, that will probably explain things somewhat. Also subsitute MDD with Agile, and realise that Agile was created under similar circumstances and you'll probably get the point.
From the title, I thought there might be something insightful about the importance and difficulty of maintaining concentration when working with the large, complex, abstract and mostly invisible structures that software consists of.
Instead it was just another riff on "we're doing it wrong"...
Garbage. The thought of letting his team know about meditation was one-sided, it is what happens when you begin to meditate; you want everyone else to do it, too. And while that isn't a necessarily bad thing, this post is missing a lot of facts - how did the team respond to meditation on a personal level, how he managed to get everyone to meditate for 45 minutes out of the blue, and how many of people continued to use meditation all together; if any at all?
16 comments
[ 4.0 ms ] story [ 46.7 ms ] thread“Buddhism is an easily understood, energy-saving teaching; people strain themselves. Seeing them helpless, the ancients told people to try meditating quietly for a moment. These are good words, but later people did not understand the meaning of the ancients; they went off and sat like lumps with knitted brows and closed eyes, suppressing body and mind, waiting for enlightenment. How stupid! How foolish!”
I think you could find lots of interesting parallels between software development and religion. To a first approximation, it's all about old guys giving advice that's misunderstood and channeled into various schemes like consultancies and conferences and churches.
> 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.
But I think this concept of self knowledge is integral to Buddhism at the least, and I know understanding it can be part of swallowing an iron hot ball in zen.
However, the conclusion is really pessimistic !
"Great developers create great software not because they follow the strictures of some methodology but because they are truly great, gifted artisans."
So...non-gifted artisans will never produce great software ? We shouldn't try to increase the average quality of software by figuring out methods that work for the rest of us that are not "gifted" ?
"Make me one with everything!" the Monk chuckles with a cheeky smile.
So the buddhist gets his hot dog and pays the hot dog vendor with a $20 bill. The vendor takes the money and expecting change the buddhist asks what is going on?
The smile is returned by the hotdog vendor; "Change must come from within".
On the other hand, I realize that this is how many millions across the world get introduced and hopefully some of these millions will discover there is more.
Why were Tim's (and his group's) projects failing before they sdopted MDD? Were many of them new at the company? Did they have a bad manager that left as they started MDD?
If their new methology is bogus something else must have changed.
This point is emphasised again later when he finds a new team in his org when MDD is failing. That team has a new manager (with 15 years dev experience), working with a new team and a new methodology QDD. Again, the team attributes success to QDD, not the people.
ie the success is down to people, not the process.
If you realise MDD (and QDD) is completely made up, that will probably explain things somewhat. Also subsitute MDD with Agile, and realise that Agile was created under similar circumstances and you'll probably get the point.
:-)
Instead it was just another riff on "we're doing it wrong"...
https://news.ycombinator.com/item?id=9104759
Like I said, garbage.