RE: [colorforth] abort

[Samuel Falvo <falvosa@xxxxxxxxx>]

> For me, specification is what the program must do; design is how it will be
> done.

Those development practices which clearly distinguishes the specification and
the design, especially those that occur at different times, are quickly finding
themselves faced with the possibility of outright extinction.

*ALL* new software development methodologies being developed today inherit the
basic practices of Extreme Programming (hereafter referred to as XP for
brevity; XP has nothing to do with Windows in this context).  These practices
include:

 1.  Extensive unit testing at the functional level.  Programmers write unit
tests for each function-point, design-point, feature request, or whatever you
want to call them.  XP calls feature requests "user stories."  There has been
many people who observed the sheer similarity between unit tests and Djykstra's
formal specifications (I think I misspelt his name, but you get the idea).

 2.  Turn-around times so rapid that you don't have time to make a distinction
between specification and design.  XP's test-first-by-intention practice forces
you to write the unit tests *BEFORE* you write production code.  This results
in a distinctly test-driven development system, where the design of the program
*evolves* from the user's specification, based on requirements that have been
hard-coded in unit tests.  That is, the design and the production code are
effectively written concurrently, permitting the high degree of interaction
between the customer and software development team.

 3.  Acceptance tests are authored primarily by the customer directly, perhaps
being translated into code by the development team.  This guarantees that the
final results of the software project fully meets the customer's requirements.

 4.  Building the software occurs constantly.  Complete integration occurs at
all times.  Nothing gets checked into CVS (or whatever) until all unit tests
pass 100%.  Acceptance tests are generally allowed to fail a little bit, but
not excessively so.  The customer is kept in the feedback loop at all times.

> Quality standards say that this first step from specification to design is
> also subject to checkings.

XP satisfies this via both unit tests and acceptance tests.

> attempt to replace or automate tests. It appeared to me that if I was not
> satisfied with tests then maybe I should review my test methods first. What
> about you? 

Generally, if your software's requirements are written in the unit tests
directly, I would try as hard as possible to modify the production code to meet
the test's requirements.  If, and ONLY if, it turns out that this isn't
feasible, should one rewrite the unit tests, making sure that the customer's
requirements are always there inside the unit tests.  The tests are key to
writing production-grade code.

--
Samuel A. Falvo II


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com