From: Joel VanderWerf <vjoel@...>
Date: 2003-11-20T15:24:15+09:00
Subject: Re: "stereotyping"

Michael Campbell wrote:
> Simon Kitching wrote:
> 
> 
> 
>>No, it's more to protect me!
> 
> 
> *chuckle*
> 
> 
>>It's to protect me from questions like:
>>
>>"Hey, what kind of object is this method expecting? It isn't
> 
> documented
> 
>>anywhere and I can't understand the source code".
>>
>>"Hey, I'm getting this message from the XXX library about do_foo
> 
> not
> 
>>existing on parameter bar. I must be doing something wrong. How do
> 
> I fix
> 
>>it?"
>>
>>"Hey, I'm supposed to fix this library method. What parameters are
>>people allowed to pass to it?"
>>
>>and the corollary question:
>>
>>"Hey, your team isn't making much progress on this project, despite
> 
> this
> 
>>Ruby language you suggested. Why shouldn't I fire you?"
> 
> 
> 
> I think it would be very illustrative to turn one of these guys loose
> 
> on a project with ruby and see what you get.  You might be 
> presupposing problems will exist where they won't... or not.  Won't 
> know till you try it though.

That kind of experience would be interesting to hear about.

Another factor that might help: supposing you have a comprehensive test 
suite and a test-first policy, you have another way of fielding 
developer questions besides digging through source or looking at 
(possibly out-of-sync) documentation: just tell your colleagues to look 
at the tests.

If you consider the specification of your software to be the test suite, 
then that is where you should look when you want to know "what kind of 
object is this method expecting" or "what parameters...".

I've never worked with a group this way, but that's often the way it 
works when I've forgotten how my own code behaves. When I'm confused, I 
look at the canonical examples that are guaranteed to work because the 
tests all pass. If there's not enough information there, then there 
should be more tests. This is really more useful than static typing, 
since it can also tell me which situations lead to which exceptions, or 
other complex input-output relationships that are not explained by just 
knowing input and output types.

> In very few cases have I just not found documentation where I needed 
> it; I haven't had to go into src code much at all (I can't really 
> remember a specific time, actually), and my only consternation so far
> 
> has been what I would consider dubious design choices, not typing
> issues.