> -----Original Message-----
> From: Ken Kahn [mailto:kenkahn at toontalk.com]
> Sent: woensdag 7 november 2001 19:11
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Three Threads Of Squeak 
> 
> 
> Here's a very simplified view of programming:
> > 1. Problems are either well-understood or not.
> > 2. Problems are either small or big.
> I think Squeak and its iterative methodology works best for 
> problems that are not well-understood. 

> I think what Justin has been arguing 
> for is changes or a redesign to best deal with problems that are 
> well-understood but large.
> That is where CASE tools, modeling, and lots of up-front 
> design has the biggest payoff. When a problem is not well-understood then
a 
> great way to understand the problem better is to jump in there and build
some code
> resulting in a better understanding. As a result of this better
> understanding the code changes and one iterates.  
> My impression is that most large software projects in insurance or banking

> are problems that are well-understood and hence this iterative exploration
isn't 
> appropriate and can be counter productive if the problem is large and
hence 
> the team is large.
> 
> Best,
> 
> -ken kahn ( www.toontalk.com )
> 
A matter of perspective? 

Problems that are far away look smaller and you cannot see all the details
from that distance.

But even if you take your own small problem and you use your magnifying
glass called analysis, your problem grows, and even worse you see more and
more hidden details of your problem.

So small or big: how can you organise your problemspace: most of the tools
of Squeak are tools to help you find things when it becomes to complicated
for a simple human. Only tools like package browser could become a help to
prevent the mess: integrated CRC-cards could, scenario's translated in
swimlanes could, etc..