[
Lists Home |
Date Index |
Thread Index
]
5/3/03 10:20:09 AM, "Michael Kay" <michael.h.kay@ntlworld.com> wrote:
>> I came across an interesting article making a similar point.
>> http://itmanagement.earthweb.com/columns/article.php/2200011
>> Basically, the author argues that XP is misnamed, it should be called
>> "Xtremely Conservative Programming"
>
>It's interesting to contrast these principles with the way I develop
>Saxon:
>>
>> "1. Conservative Planning -- Plan only for the next release.
>
>I don't even do that. My rule is "no planning allowed".
>
>> 2. Conservative Scope Management -- Build the smallest
>> deliverable possible
>
>I reckon that if I ship more than once every 2-3 months, users won't be
>able to keep pace.
>
>> 3. Conservative vision -- Explain your design with a simple
>> metaphor that
>> everyone understands.
>
>Not my problem: writing the spec and implementing it are completely
>separate activities (even if I'm involved in both!)
>
>4. Conservative testing -- Test everything, all
>> the time.
>
>I've often taken the opposite approach. Some things are very easy to
>code but quite difficult to test. The users will tell you if it doesn't
>work. If they don't, chances are the bugs don't matter.
>
>5. Conservative coding -- Programmers aren't allowed to write any code
>without
>another programmer partner watching over their shoulder..."
>
>No one is allowed to write any code except me.
I think the key here is that Saxon is "small enough" for one person to "get himself around it"
completely, and the methodology you describe is entirely appropriate for such cases. XP, on the
other hand, seems to me to be a methodology intended for programming projects that are "too big" to
be entirely the purview of one person. It's a fallacy to assume that the former will scale up to
handle the latter, *or* that the latter will scale down to handle the former. There's no "one size
fits all" solution. Trying to find the One True Methodology and apply it uniformly to all tasks is
a recipe for failure.
|
