in reply to Specify, Specify, Specify

The Perl way (and the extreme programming one BTW) uses more tests than specifications. Specifications are like consultative assemblies, they have no direct enforcement power. They can't have until they are translated into enforcing tests.

The problem of specifications is the choice of language. Specifications in common language are accesible to everyone including management and customer, but they are ambiguous. Specfications in a more formal language are hard to write and to read.

In a sense, tests are a form of specification. The big problem is that they are only palatable to programmers.

-- stefp

  • Comment on Re: Specify, Specify, Specify (or test, test, test ... and taste)

Replies are listed 'Best First'.
(Ovid - XP) Re(2): Specify, Specify, Specify (or test, test, test ... and taste)
by Ovid (Cardinal) on Oct 01, 2001 at 20:50 UTC

    I've seen a couple of mentions of XP in this thread and, while I haven't looked into too deeply, I'm not sure of its utility for certain projects.

    One project that I'm currently working on requires some very difficult database design with products that have widely varying specifications. Books have bindings and a publisher, fishing lures have type of material and the type of fish they're for, clothes have sizes, etc. Because the nature of the products that we get in will change dramatically, creating separate tables for each will not be an option (not to mention that this would violate first normal form and cause us a lot of headaches). As a result, I've "conceptualized" a scheme where each attribute would be in a separate table and I would have a lookup table matching products and attributes. This seems easy, but then we wind up with display problems. How do we organize a variable number of product attributes in an aesthetically pleasing and comprehensible way for the end user. Also, we need to access information regarding the structure of the database so that when we dynamically generate input forms for our dealers, we don't need to worry about them entering a 2000 word description for an item that only takes 255 characters. This seems to imply a lot of careful design work up front, but XP seems to slough that off in favor of tests. I really don't see how one skips designing complicated systems in favor of testing it. How do you manage that?


    Vote for paco!

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

      I've seen a couple of mentions of XP in this thread and, while I haven't looked into too deeply, I'm not sure of its utility for certain projects.

      XP stands here for eXtreme Programming, not eXperience points. :)

      I am no specialist of extreme programming. I have hardly started to read extreme programming explained on safari (they got non O'Reilly books now). XP seems to me another name for Larry's whirlpool. Instead of the waterfall model where stages are sequential, the whirlpool model retrofit in the specifications the experience of "later stages".

      The problem with the whirlpool (alias XP) is that it asks every involved person to closely follow the project in every aspects which is probably incompatible with a marked hierarchy or a customer who don't want to be involved in every stages of program development: "He, we outsource that chore because we dont want do bother with it. Come back when you are done."

      Probably the whirpool model works best in Open Source Project (like parrot). Flexible languages like perl encourage very fast iterations so it is no surprising that Larry came first with the whirlpool metaphor (without the hype of exterme programming).

      To answer you concern: the emphasis on early tests is to get early feeback. It permits to "enforce" the specification -- like I said in the previous node -- or to update it. I don't think the whirlpool model encourages to supress specification. Each iteration involves each of the stages that follow each other in the waterfall model.

      -- stefp