The vibe this week: hunting down obscure problems.
While I've been going through profiles of bizarre performance behavior one
agonizing step at a time, the Twisted Matrix server has been on the
fritz.
Exarkun is at the facility right now, taking the server's case off, poking
the components with sticks, and generally abusing it. Right now we're
thinking maybe it's a problem with the CPU fan, but since it starts off
spinning at 4000 RPM, it seems unlikely that it's the fan itself that's
broken.
I'm back in Boston and ready for action. Regarding the topic, I always
misspell this:
This weekend I'm going to be back in NY yet again. Sorry, boston people.
I read Ward Cunningham's interview at artima recently, and had a bit of an epiphany about Extreme Programming.
In particular it was an epiphany about the YAGNI and DTST rules. I always assumed, based on the examples that were given, that the rules were meant to say "keep it simple, because that's probably good enough anyway". In other words, if you are sure that the simple approach isn't going to work, if your customer requirements include stuff outside the scope of the simple solution, you should use a more complex solution until you can encompass all the requirements. It should be no more complex.
Ward seems to be saying that this is wrong: that the goal is not to arrive at the simplest correct solution, but to arrive at the simplest solution that moves you forward, even if you know it's wrong. In fact, especially if you know it's wrong. Because you're going to arrive at the wrong answer multiple times anyway, it's very important that those answers be simple. Even if you can see deficiencies in your solution as you're implementing it, it's better to complete it quickly, put it in front of a customer, and determine experimentally whether the deficiencies you've spotted are as important as those the customer spots.
What I'm taking away from this article is that the key thing is release velocity, not correctness of the implementation or completeness of requirements analysis. The customer will change their mind. The estimates will be wrong. The only way you can compensate for this is by making changes cheap. The only way to make changes cheap is to practice making changes, and the only way to get practice is to make a lot of changes.
Being a drinker of XP kool-aid for quite some time now, it's funny how this still seems so counterintuitive to me. Looking at it sideways, though, it's a really distilled worse-is-better, with a much more narrowly-defined definition of how to "win big".
So, what do you think? Does "you have to do it wrong before you can do it right" sound like an accurate aphorism, or am I distorting Ward's words?
In particular it was an epiphany about the YAGNI and DTST rules. I always assumed, based on the examples that were given, that the rules were meant to say "keep it simple, because that's probably good enough anyway". In other words, if you are sure that the simple approach isn't going to work, if your customer requirements include stuff outside the scope of the simple solution, you should use a more complex solution until you can encompass all the requirements. It should be no more complex.
Ward seems to be saying that this is wrong: that the goal is not to arrive at the simplest correct solution, but to arrive at the simplest solution that moves you forward, even if you know it's wrong. In fact, especially if you know it's wrong. Because you're going to arrive at the wrong answer multiple times anyway, it's very important that those answers be simple. Even if you can see deficiencies in your solution as you're implementing it, it's better to complete it quickly, put it in front of a customer, and determine experimentally whether the deficiencies you've spotted are as important as those the customer spots.
What I'm taking away from this article is that the key thing is release velocity, not correctness of the implementation or completeness of requirements analysis. The customer will change their mind. The estimates will be wrong. The only way you can compensate for this is by making changes cheap. The only way to make changes cheap is to practice making changes, and the only way to get practice is to make a lot of changes.
Being a drinker of XP kool-aid for quite some time now, it's funny how this still seems so counterintuitive to me. Looking at it sideways, though, it's a really distilled worse-is-better, with a much more narrowly-defined definition of how to "win big".
So, what do you think? Does "you have to do it wrong before you can do it right" sound like an accurate aphorism, or am I distorting Ward's words?
Since so many of you have asked, the google bar that reads "coolpix battery"
in my recent screenshot is there because I was looking for a
way to fix the broken battery
indicator on my digital
camera.
(If you want to ask questions like this in the future, consider using the livejournal comments option, rather than personal email or IRC /msg. I do read them.)
(If you want to ask questions like this in the future, consider using the livejournal comments option, rather than personal email or IRC /msg. I do read them.)