Re: [Edu-sig] Python as Application

2005-11-01 Thread 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
[EMAIL PROTECTED]

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig


Re: [Edu-sig] Python as Application

2005-11-01 Thread Kirby Urner
 That's fine, but call a spade a spade. I don't like seeing technical
 programs masquerading as bachelor's degrees. We have plenty of
 technical colleges people can go to for that sort of thing. It's the
 deception I object to.
 
 --
 Best regards,
  Chuck

Fair enough, though I also find academia's nomenclature somewhat broken, as
well as medieval.  All these philosophy doctors (weird).  

Employers have to look well beyond just the degree stuff, to get a sense of
what a candidate might actually know or be able to do.

Kirby


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig