(Hi Honey, I'm Hooooooome.)

Folks...

I just read the last month's messages. The following comments
apply both to the many questioners AND the many answerers.

Stop thinking so much. Stop worrying so much. Stop biting off
so much.

I know, I know, we all got to be good at this business precisely
because our overly-buff neo-cortices are good at juggling and
balancing bizarre abstractions. I *know* we all have good
memories, good verbal skills, and the ability to hold multiple
levels of analysis in our heads, not to mention API calls
and argument lists. I know we're the world's greatest
generalizers and that before we even hear the full description of
two ideas we've already abstracted them into a base idea and two
derived ideas. I know. I'm there, too. Nevertheless, stop doing
it.

Try these two chips off the iceberg:
<http://c2.com/cgi/wiki?ToAyoungExtremist>
<http://c2.com/cgi/wiki?AjiKeshi>

Here are some specific comments from my reading...


1. Unbelievably complicated unit testing frameworks: You don't need
them. You need the ability to write a test function, add it to a
list of test functions, and call them. How long will it take you
to write that code? Four hours? Six? Write it. Over time you
may see other things that will be handy, but you don't need them
now.

2. Corner cases you've invented where the XP method seems to
have contradicted itself: You don't need them. If you really
encounter them in the field, which for the most part I seriously
doubt you ever will, here's how you solve them. 1) Pick one
interpretation or the other. 2) Implement it. 3) Try it.
4) If you don't like it, change it until you do. 5) If you can't
change it enough, pick the other interpretation.

3. Unbelievably-difficult-to-unit-test classes you've created:
You don't need them. If it can't be unit-tested, it can't be a
stable central part of your code, so throw it away. Divide one
staggeringly complex object into thirty dead simple ones. Unit
test them.

4. Umpty-nine-levels of inheritance and abstraction with private
inner reverse-schreck semiotic slipsoid sub-class interactivity
devices that make your design impossible to even describe, let
alone debug: You don't need them. I am truly staggered to hear
how many folks are using the arcana of their programming
environments rather than the mainstream.

5. The generic solution to all problems having to do with a
generalized and abstract class representing XXXXX's: You don't
need it. You need a class representing XXXXX's AS SEEN BY YOUR
CUSTOMER'S USER STORIES. Code one. Forget about dividing the
world up into philosophically correct hierarchies. Divide the
*problem* into *pragmatically* correct ones.

6. Unit tests that are designed to prove that your object will
survive a thermonuclear blast: You don't need them. Unit tests
should be renamed object tests, an argument I'll take up later.
Write a unit test to test ONE object, not all that objects that
one talks to. If you cannot find a way to do it, your object is
almost certainly too complicated. Simplify it, and try again.

7. Unit tests that are really functional tests: You don't need
them. The functional tests prove that everything works together
to satisfy the customer's stories. The unit tests do not exist
to prove that your program is correct. They exist to make your
work faster and easier. Pretend your object is floating in a
petri dish, not in a live cell. Test it *without* testing its
neighbors. If you can't, re-write until you can.

8. Paint-scraper programs that capture and test screen output
for form-based apps: You don't need them. De-couple all
program functionality from UI functionality. Unit-test it.
Write generic client-controls that use generic data-servers.
Unit-test them. Derive concrete data-servers connected to your
model. Unit-test them. Build forms by connecting clients to
servers. Unit-test them for tab-order and screen-layout.
Get your functionals to 100%. Ship. Wait for stock options to
mature.


Okay okay, enough already, I know. My apologies in advance for
seeming altogether too cranky. But sheesh...

Good night!
Hill


+----------------------------------------------------------+
|Michael Hill |
|Software-> Developer, Consultant, Teacher, Coach |
|Lifeware-> Egghead, Romantic, Grandpa, Communitarian |
|<uly@...> or <uly56@...> |
+----------------------------------------------------------+