XP makes randomness safer than clockwork [Was: Break out of]

[Phlip]

Guys,

At a recent XP meeting, they asked if so many constraints on code production
make changing large subsystems - the answer is nothing speeds change like
never not changing anything else.

So if a colleague asks a question, you only change a test to answer it.

Like a haiku detector set loose on your bedroom floor, this sucks up bugs.

International penpals, these things constrain.

Constraints produce a phase space, with vectors. We only need flatten the
floor; a solid layer of continualy passing tests.

They align on better code. Via change.


From: Steve Jorgensen

I'm committed to trying to move from Access programming to OOP/TDD, and
I'm looking at moving to C# and/or Java. So, I'm trying to think of projects
to try to implement as self-teaching projects.

Have any significant others put a day-care center on your credit card?

Read Mike Feather's startup work "welc". Take a sf.net program, and try to
upgrade it.

You'll find yourself expanding its sample code into a test.

If no sample code, reject and audition the next one.
I've read enough now here and elsewhere to know that for TDD, the idea is usually to try to keep the UI as thin as reasonably possible since that's
the hardest thing to write tests for, and code as much as possible to be UI agnostic. That sounds great, but my brain is having trouble bending that
way.

The GUI story is here: http://www.c2.com/cgi/wiki?TestFirstUserInterfaces
It's not that Access is the only thing I've ever known. I started out programming in Applesoft Basic, taught myself Assembly Language, then went
on to C, Modula II, ad did a fair amount of hobbying in C++ before ending up
working in database development using Paradox, Foxpro, then MS Access.

Is your GUI already thin in the stories?

If its thick, your tests must reach in from the GUI Layer. That's not the
nail then - it's the hammer.
Still, I find I've been steeped in Access for so long that my thought
process is that everything starts out as a UI tied to a back-end, then sprinkle code
as necessary (I'm a hammer now, and every problem looks like a nail to me).
How to I develop a replacement way of thinking to break out of this? What does a
thin UI feel like? How does code that now seems like an extension of the UI
begin to feel like a part of the internal process instead?
Any tips? Links? Books?

Yeah. All 3.

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

[Jeremy Dunck]

On Sat, 12 Jul 2003 22:09:53 GMT, "Phlip" <phlip_cpp@yahoo.com> wrote:
Guys,At a recent XP meeting, they asked if so many constraints on code productionmake changing large subsystems - the answer is nothing speeds change likenever not changing anything else.So if a colleague asks a question, you only change a test to answer it.Like a haiku detector set loose on your bedroom floor, this sucks up bugs.International penpals, these things constrain.Constraints produce a phase space, with vectors. We only need flatten thefloor; a solid layer of continualy passing tests.They align on better code. Via change.

I'm just sure that meant something, but I'm not squinting at it right.

<snip>Is your GUI already thin in the stories?If its thick, your tests must reach in from the GUI Layer. That's not thenail then - it's the hammer.

Wha?

<snip>
Got any of that green cheese?

*ponder*