David Buck has this article "Domino Changes With Static Typing".  Its a good article with a couple of key observations.

He explains that a primary justification of encapsulation is that of a local change having only a local effect:

There is one primary justification of encapsulation. It's a principle I call "Local Change - Local Effect". If you change code in one spot, it should only require changes in a small neighborhood surrounding the original change. When used properly, encapsulation allows software to change gradually without requiring bulk changes throughout the system. This is critical for maintenance programming. If you use an agile development methodology like XP, then you are always in maintenance mode.

He goes on to describe a problematic situation when having to change a const declaration in C++. He sites the problems of Java's checked exception handling.  Then he makes the argument that static typing makes code more difficult to change, and therefore breaking the "Local Change - Local Effect" principle.

Interestingly, the two examples he sites "const declarations" and "checked exception handling" are vivid examples of the problems of static checking.  Both constucts seem to work well for small programs, however they don't seem to scale.  Could it be that static typing works well for small programs and more of a nuisance with larger ones? I tend then to agree with the observations, static types tends to propagate throughout a system, and will have a domino change effect. That is, for "Programming in the Large", static type checking is problematic.

However, does that mean that we should get rid of static type checking altogether?  I think that's too radical, any kind of static checking is extremely useful.  However, we should always make an effort examine the extent of the static dependencies inside our system.  Large systems tend to use a combination of both static and dynamic checking.  For example, Eclipse is a large scale progam however its able to overcome the problems of static type checking.  I don't believe that there's a Smalltalk program of comparable size to the Eclipse project.  The evidence therefore exists that you can build large programs with static typing, however its interesting to know how to do this.

Large programs developed in a statically typed language is successfully acheived by exploiting a Component Model.  That is, you structure the composability of your application in terms of a component model that uses dynamic typing.  The advantage of using a statically typed language like Java over a dynamic typed one like Smalltalk is that with Java you can develop in both modes instead of exclusively in one. I think this alone statement sinks David Buck's arguments for Smalltalk.