[Edu-sig] Python as Application

[Scott David Daniels]

Arthur wrote:
> ....  One of the things I *did* do is develop
> my own kind of test suite - having come to understand the importance of
> doing so, for a futzer.  On the other hand there isn't that there are
> significant tests being passed now that wouldn't have been passed in an
> earlier iteration.  The tests are there mostly as an assurance that my
> refactoring does not have me going backward.  But offer no particular clue
> about how to go forward.  So, my kneejerk reaction to test based development
> is some fear that it would lead to a development style that makes passing
> tests good enough.  On the other hand, I don't fully understand the workflow
> that test based development recommends and where it leads.
You'd have a lot of fun talking with Ward for a day.  I am not completely
sold on test-driven development myself, but I lean there which is why I
call my current style test-forward.  By that I mean I put the tests as
early in the process as I can stand.

Two things that _are_ important in Ward's ideas and mine are: start with
tests that fail and make them work.  It is _shockingly_ easy to make a
test that accidentally succeeds even in the face of bad code.  More than
once I've written a bad test, and eventually figured out that the test
itself is bad.

> When I do commercial work I have a pretty good idea where "good enough" is -
> would the client (who doesn't really understand my process) want to pay for
> further refinement (if they did understand my process).   When I come to a
> "no" - I stop. It's never that there aren't further refinements that could
> be accomplished.
In the for-money world, there are two other things Ward advocates.
You break the work into tiny _costed_ chunks, some of which produce
customer-visible results (and, perhaps) some of which do not).  The
ones you cannot make customer-visible get tied as pre-requisites to
customer-visible chunks.  You then let the customer choose what to
work on next.  The tests help confirm you are moving forward, not
around.  The estimates change, but the customer is tied in enough
that he sees the new estimates each round.  His choices are rarely
the order you would choose, but they are his choices, not yours.

Generally you try to make the chunks reflect equal amounts of work
that are quickly terminable (half-day or day, for example).  If you
don't complete a task, you either put it back in the pile or (more
likely) make new subtasks that finish this work.  You track both
your over-all progress, and the speed at which you dispatch tasks.
You start calling your progress "four cards per week," for example.
Your customer comes to see you hitting your estimates, and trusts
the process more.  You get better at estimating and teasing out
prerequisites.  You can even include tasks that are "break the goal
into tasks" if the estimate is too shaky for your tastes.

A couple of things I like about this model: it keeps you honest in
promising what will happen, and it keeps your customer honest in
that he is not asking for "free" work -- only costed trade-offs are
available to choose from.

--Scott David Daniels
Scott.Daniels at Acm.Org