Break out of "every problem looks like a nail"?

Break out of "every problem looks like a nail"?

Post by Steve Jorgense » Mon, 14 Jul 2003 05:50:08



Hi all,

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.

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.

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.

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?

Thanks,

- Steve Jogensen

 
 
 

Break out of "every problem looks like a nail"?

Post by Robert C. Mart » Mon, 14 Jul 2003 12:29:35



written this on (or about)  Sat, 12 Jul 2003 20:50:08 GMT, :

Quote:>Hi all,

>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.

>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.

>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.

>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?

Here's an exercise that will take you a few hours, and will teach you
what you want to learn.  Write the game "Hunt the Wumpus".  This is a
very simple game from the 70s that people used to write in Basic on
their Apple II or TRS-80, or Commodore 64.  

Play it here: http://www.taylor.org/~patrick/wumpus/

As I said, write this game.  HOWEVER, write absolutely no user
interface code!  Write test cases that check to see that every
function works.  Also write test cases to make sure that the program
knows what messages to emit and the right times.  However, do not
include the strings of the messages, and do not emit the messages on
any device.  Instead, write an interface (in Java) that has methods
for emitting the appropriate messages, but have the tests implement
the methods simply to verify that they were called at the right time.
Do not write code that reads commands from the user.  However, *do*
write tests that invoke the functions that such commands would invoke.

I've done this exercise a few times, and it's always *very* revealing.
You can write the entire game without any UI.  You can get the whole
game working without every playing it.  And then, finally, as the very
last step, you can write the UI itself.  You'll find that writing the
UI is trivial once you've gotten the whole rest of the program
working.  You'll realize that you have thought through lots of issues
that make the UI simple to create.  And yet the UI will be completely
decoupled from the game.  The game won't care about the UI at all.  

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

Break out of "every problem looks like a nail"?

Post by Steve Jorgense » Mon, 14 Jul 2003 13:03:42


On Sat, 12 Jul 2003 22:29:35 -0500, "Uncle Bob (Robert C. Martin)"



>written this on (or about)  Sat, 12 Jul 2003 20:50:08 GMT, :

>>Hi all,

>>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.

>>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.

>>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.

>>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?

>Here's an exercise that will take you a few hours, and will teach you
>what you want to learn.  Write the game "Hunt the Wumpus".  This is a
>very simple game from the 70s that people used to write in Basic on
>their Apple II or TRS-80, or Commodore 64.  

>Play it here: http://www.taylor.org/~patrick/wumpus/

>As I said, write this game.  HOWEVER, write absolutely no user
>interface code!  Write test cases that check to see that every
>function works.  Also write test cases to make sure that the program
>knows what messages to emit and the right times.  However, do not
>include the strings of the messages, and do not emit the messages on
>any device.  Instead, write an interface (in Java) that has methods
>for emitting the appropriate messages, but have the tests implement
>the methods simply to verify that they were called at the right time.
>Do not write code that reads commands from the user.  However, *do*
>write tests that invoke the functions that such commands would invoke.

>I've done this exercise a few times, and it's always *very* revealing.
>You can write the entire game without any UI.  You can get the whole
>game working without every playing it.  And then, finally, as the very
>last step, you can write the UI itself.  You'll find that writing the
>UI is trivial once you've gotten the whole rest of the program
>working.  You'll realize that you have thought through lots of issues
>that make the UI simple to create.  And yet the UI will be completely
>decoupled from the game.  The game won't care about the UI at all.  

Sounds like very straightforward advice.  I shall try that.  Thanks.

This also sounds like a good exercise for trying out other programming languages
like Perl, Python, C#, Haskell, etc. (still haven't found much info regarding
TDD w/ FP, though).

 
 
 

Break out of "every problem looks like a nail"?

Post by Phli » Tue, 15 Jul 2003 01:16:22



Quote:> Here's an exercise that will take you a few hours, and will teach you
> what you want to learn.  Write the game "Hunt the Wumpus".  This is a
> very simple game from the 70s that people used to write in Basic on
> their Apple II or TRS-80, or Commodore 64.

> Play it here: http://www.taylor.org/~patrick/wumpus/

> As I said, write this game.  HOWEVER, write absolutely no user
> interface code!  Write test cases that check to see that every
> function works.  Also write test cases to make sure that the program
> knows what messages to emit and the right times.  However, do not
> include the strings of the messages, and do not emit the messages on
> any device.  Instead, write an interface (in Java) that has methods
> for emitting the appropriate messages, but have the tests implement
> the methods simply to verify that they were called at the right time.
> Do not write code that reads commands from the user.  However, *do*
> write tests that invoke the functions that such commands would invoke.

> I've done this exercise a few times, and it's always *very* revealing.
> You can write the entire game without any UI.  You can get the whole
> game working without every playing it.  And then, finally, as the very
> last step, you can write the UI itself.  You'll find that writing the
> UI is trivial once you've gotten the whole rest of the program
> working.  You'll realize that you have thought through lots of issues
> that make the UI simple to create.  And yet the UI will be completely
> decoupled from the game.  The game won't care about the UI at all.

A "Representation Layer" turns one representation into another. In the above
exercize, the Wumpus Layer may have an object model the user would not
expect. The goal is to write a Representation Layer that has an object
module an end-user would recognize, if they grokked its notation.

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

 
 
 

Break out of "every problem looks like a nail"?

Post by Robert C. Mart » Tue, 15 Jul 2003 06:16:17



on (or about)  Sun, 13 Jul 2003 16:16:22 GMT, :

Quote:>A "Representation Layer" turns one representation into another. In the above
>exercize, the Wumpus Layer may have an object model the user would not
>expect. The goal is to write a Representation Layer that has an object
>module an end-user would recognize, if they grokked its notation.

I don't think so.  I don't care if the end user groks the internal
representation.  I want the internal representation to be convenient
and obvious to the programmers, not the end user.

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

Break out of "every problem looks like a nail"?

Post by Phli » Tue, 15 Jul 2003 12:49:00


Quote:> >A "Representation Layer" turns one representation into another. In the
above
> >exercize, the Wumpus Layer may have an object model the user would not
> >expect. The goal is to write a Representation Layer that has an object
> >module an end-user would recognize, if they grokked its notation.

> I don't think so.  I don't care if the end user groks the internal
> representation.  I want the internal representation to be convenient
> and obvious to the programmers, not the end user.

The facade of the representation layer that the GUI layer uses can do
anything the GUI can, the same way it does it. Where the GUI picks from a
list, the representation layer indexes an array; same thing.

I think that has been said before, somewhere.

In this case (so far as I grok Wumpi), the two functions would be
shootAtTheWumpus(x,y) and move(x,y).

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

 
 
 

Break out of "every problem looks like a nail"?

Post by Steve Jorgense » Thu, 17 Jul 2003 17:13:08



>Hi all,

>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.

>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.

>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.

>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?

>Thanks,

>- Steve Jogensen

Status update...

I plan to follow Bob's advice about Hunt the Wumpus, but I found I needed some
even more pedantic help to get me started since I'm new to Java, JUnit, and TDD
all at the same time!

I found an answer at xp123.com/xplor/xp0201.

With this challenge, I start with tests that someone else has already written
(one at a time - no looking ahead), and follow all of the other incremental TDD
rules.  This way I get to see what a good progression of simple test ought to
look like before I try to start writing my own tests on my subsequent Hunt the
Wumpus exercise.

 
 
 

Break out of "every problem looks like a nail"?

Post by Ilja Preu » Thu, 17 Jul 2003 23:27:40



> I plan to follow Bob's advice about Hunt the Wumpus, but I found I
> needed some even more pedantic help to get me started since I'm new
> to Java, JUnit, and TDD all at the same time!

> I found an answer at xp123.com/xplor/xp0201.

> With this challenge, I start with tests that someone else has already
> written (one at a time - no looking ahead), and follow all of the
> other incremental TDD rules.  This way I get to see what a good
> progression of simple test ought to look like before I try to start
> writing my own tests on my subsequent Hunt the Wumpus exercise.

It's a nice exercise. I already had some experience doing TDD when I tried
it, though. I found that I prefer to work in even smaller steps than the
exercise seems to propagate - so if you get stuck or find that it takes more
than a few minutes to make a test run, try to break them down further!

Regards, Ilja

 
 
 

Break out of "every problem looks like a nail"?

Post by Ilja Preu » Thu, 17 Jul 2003 23:34:02



> It's a nice exercise. I already had some experience doing TDD when I
> tried it, though. I found that I prefer to work in even smaller steps
> than the exercise seems to propagate - so if you get stuck or find
> that it takes more than a few minutes to make a test run, try to
> break them down further!

As an example, I would probably implement the five blocks in
testThatNumericCellsAreIdentifiedAndStored one after the other.

Regards, Ilja

 
 
 

1. "own" vs "uses" vs "contains" vs "is a"

I am studing for a VB exam and the book I have mentions there are
relation types between objects. (New Riders pg. 22 "MCSD Visual Basic
6 Exams 70-175 and 70-176".  (FYI - I did take a course in Object
Oriented Design!)

The book does not give any examples, but I have come up with the
following examples for the relation types that the book says exist. I
came up with the examples etc. from another book by Kurata ( Doing
objects in Visual Basic 6".

My question is how is "contains" different from "has a" I cannot come
up with an example.

"is a" - example a programer "is a" employee. In VB this might be
called a subclass.

"uses" - a data screen "uses a" employee object. In VB this might be
called a collaborator.

"has a" - and employee "has a" time sheet. In VB this might be called
a container.

"contains" -

2. these forums

3. Looking for examples comparing "traditional OO" vs. "component OO"

4. Latest Cisco IOS Version/Revision ?

5. Looking for "state" and "display" objects in C++.

6. Relaying SMTP's?

7. Removing "My Computer", "Recycle Bin" and "Network Neighborhood" from desktop

8. money 2001 and syncing with pocket PC

9. Why "public" "private" "protected"

10. extern "FORTRAN", extern "Pascal", extern "Ada" ... ?

11. Windows "Large Fonts" <--> "Small Fonts" problem...

12. Problem with "string" in a "class".