Divmod and Twisted have instituted a fairly rigorous development process over the last few months. I'm very happy with the results, but there have been several objections to the strict enforcement of apparently useless or trivial parts of the policy, especially as related to small or mechanical changes.
When I was a wee lad, I took violin lessons according to the Suzuki Method. In the Suzuki Method, the first thing you do in your violin lessons (if you are a 4-year-old, anyway) is make a "violin" out of a cracker jack box and a ruler. For months, I did nothing but sit, then stand, hold the cracker jack box, extend it outward, and place it under my chin, hold it there, remove it, tuck it under my arm, and sit back down. I had to draw a diagram, on a poster, which showed where my feet were supposed to go while performing these steps. Then I stood on that diagram, placing my feet in the appropriate positions.
You are not allowed to use a real violin until you can get every step of this exactly correct. As a kid, that was pretty cool. When you have progressed to the point where you are allowed a real violin, you get to open the box and eat the cracker jacks. Parents, however, were often unhappy with this particular trajectory of violin training. Their 4-year-olds were eating cracker jacks six months after starting violin lessons, and students in other methods (read: their hypercompetitive co-workers' children) were playing Twinkle Twinkle Little Star on their shiny new violins at Christmas and Thanksgiving, much to the approval of the assembled family.
Of course it looks ridiculous to results-obsessed American parents to be messing around with crude drawings of your feet and tiny cardboard boxes when what you're ostensibly doing is learning to play an instrument. Why not move on to the instrument directly and focus on the important parts of playing, like fingering and tone and harmonics and sight-reading and so-forth?
The Suzuki Method was invented by a japanese fellow, and it follows the japanese sensibility that requires even trivial tasks to be performed according to extremely rigid rules. Have you ever watched a sushi chef prepare a meal? The next time you do, observe what they do when they wash their hands. They will always position a bowl of water in exactly the same position. They will always dip their hands in the water the same number of times. The knife will always be placed in the same position, picked up and put down at the same exact moments before and after slicing the fish. I don't know how to prepare sushi myself, but I've observed the pattern at every sushi bar I've sat in, from San Jose to Austin to Florida.
There is a reason why we focus on the small details of the development process. If there is an obviously correct way to do something, it should be done that way. Why expend effort on every method trying to decide whether it "should" be documented? Document everything. Why create elaborate rules for what "should" be tested? Test everything.
Those kids who were playing "twinkle twinkle" six months before I was? Well, I got to play with them later, in school and community orchestras. Some of them even became quite good violinists. However, there were certain differences you can easily pick up on. You can spot a Suzuki student because they sit straight; they hold the bow properly and lift the violin with their chin, not with their arm. A less methodical violinist will slouch, hold the violin wrong, hold the bow at an angle, and generally require more effort to play even simple songs. In fact, they will especially require more effort on simple songs, because the Suzuki student has every automatic aspect of playing completely ingrained in their muscle memory. No conscious thought is expended on the things that don't require it.
Not all the first-chair violinists I've played with learned on the Suzuki method, but they all know how to hold the instrument correctly without thinking about it.
Migration Report
1 day ago
7 comments:
I posted to TPML today and we're apparently in the progress of having a lively discussion about the things I said (although maybe it's over now, who can tell?). It happens to deal with the development process on Twisted specifically, and some objections I have to the policy process in general and a particular piece of the policy in particular.
Here's the advantage the Suzuki method has: people have been playing the violin for *hundreds of years*. They pretty much know what works and what doesn't.
People have been doing software development for only decades; wide-scale Internet open source development for far less. We really have *no idea* what works in general; we don't even have much of a clue what works for us, or we wouldn't be changing our methodology all the time.
In the face of this situation, I think it benefits us most if the policy itself is flexible, so we can compare methodologies without committing to them.
wow.
I didn't learn the Suzuki method, but I'v eplayed violin since I was...9?
:)
I guess it's going to be a bit longer before I get to open my box of cracker jacks.
What are cracker jacks?
Popcorn and peanuts covered in caramel.
Basically pure sugar. Excellent 4-year-old food.
I can't quite make the jump from rigorous training on a mock system being good to controlled processes on a real system being good -- even though I think both are good.
Incidentally, what you describe sounds exactly parallel to the "wax on, wax off" sequence in The Karate Kid.
Rigorous training on a mock system and rigorous enforcement of policy on a real system are both ways of increasing focus on basic techniques. At least, that's what they are in this context - if you are trying to enforce complex, non-basic things with your policy, my experience is that it's too vague and complex to actually be of much use.
I should have commented earlier.
Briefly, I agree with you to some extent, and I'm glad to see this point of view represented here.
However, it is expressly because we don't know what works in the large, that getting stuff right in the small is important. That was the original genius of XP; everyone agreed that peer review was important, that testing was important, and that integration was important. So XP said, okay, let's do testing, let's do peer review, let's do integeration, all the time, instead of just saying it's important.
UQDS was a similar idea; it's a huge pain in the ass every time we have to reverse-engineer code without any documentation, and it's demonstrably easier to write the documentation at the same time as we're writing (or updating) the code. So, since we know, in all of our collective experience, that the latter is cheaper (and you never end up not doing the former) let's just require it every time. Similarly for trying to figure out what changed between two revisions of trunk.
There are lots of insanely hard problems, like, what's the proper granularity for testing and to what degree should efficiency be emphasized and to what degree should tools be standardized between developers and should your office door open or closed, so the few simple things we do understand should be done rigorously and frequently.
(Or, more simply, if you don't agree with these experiences: you have to try a methodology for long enough for it to take root and see second-order effects in order to meaningfully compare it. Twisted is not all software, so there's lots of other projects and methodologies to compare to...)
Post a Comment