IMNSHO, if you have a team of 200 doing <any> software development in any language, then you have a big IT shop.  That also means you have a pretty onerous process in place that will bring all forward motion to a halt.  I'd go so far as to say that if you think you need 200 people for your project, go outside and light $100 bills on fire instead.  It will burn less money, and annoy fewer people.

On Jan 28, 2012, at 5:57 PM, Dale Henrichs wrote:

> Sven,
> 
> Keep in mind that I'm talking about making it possible for teams of 200 to use Smalltalk (or 20 teams of 10, or 20 teams of 4) ... 
> 
> How many Smalltalk developers rebuild their image from scratch multiple times per hour (day/month/year) during a development cycle ... If Smalltalk developers had to build their images over and over again on a daily basis, we would have had good tools for building images a long time ago:)
> 
> Because Smalltalk is am image it isn't necessary to build from scratch very often, but because we as a group haven't focussed on making it easy it is unnecessarily hard ... and building from scratch is a prerequisite to being used in large projects ... 
> 
> As I said, I don't think the problem is insurmountable...and I do think we are getting better.
> 
> It's just that if tomorrow a team of 200 walked up to my door and said they wanted my help in setting up their Smalltalk development environment, I'd gulp and say "give me a couple of months (at least)"...
> 
> Dale
> 
> ----- Original Message -----
> | From: "Sven Van Caekenberghe" <sven at beta9.be>
> | To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
> | Cc: "VWNC" <vwnc at cs.uiuc.edu>, Pharo-project at lists.gforge.inria.fr
> | Sent: Saturday, January 28, 2012 11:08:08 AM
> | Subject: Re: [squeak-dev] Smalltalk for small projects only?
> | 
> | Dale,
> | 
> | On 28 Jan 2012, at 19:07, Dale Henrichs wrote:
> | 
> | > Janko,
> | > 
> | > I think the limitation for Smalltalk lies in source code management
> | > tools/styles ...
> | > 
> | > With a file-based language 200 engineers can contribute to the
> | > project ...  each engineer can checkout a version of the system
> | > work in isolation then commit his or her work to the shared
> | > repository resolve conflicts and move on .... other engineers can
> | > easily integrate the work and so on ... the source code management
> | > tools scale ...
> | > 
> | > In the mid nineties at ParcPlace systems the image was passed
> | > around from engineer to engineer so that he or she could integrate
> | > their work into the production image... this doesn't scale...
> | > 
> | > There have been proprietary source code management tools that have
> | > been created over the years. You can bet that the large companies
> | > that are invested in Smalltalk are using systems that are based on
> | > these proprietary systems, but you can also bet that they've had
> | > to customize those systems for their needs...
> | > 
> | > The file-based SCM systems work out of the box and don't care what
> | > language or even development process that is being used ... they
> | > are managing files ...
> | > 
> | > There is no standard SCM for Smalltalk and none of the file-based
> | > SCMs really fit Smalltalk. When we are arguing about whether git
> | > or mercurial is better on the Pharo list, I will retract that
> | > statement:).
> | > 
> | > Without a standard SCM, the first thing that a 200 person
> | > engineering groups needs to do to start using Smalltalk is figure
> | > out (for themselves) how to share their work and keep 200
> | > individual images in synch ... I'm not necessarily convinced that
> | > anyone has really solved this one.
> | > 
> | > Personally I believe that the problem is surmountable, but for
> | > whatever reason the Smalltalk community hasn't focussed on
> | > seriously addressing the SCM issue .... in the last 30 years or
> | > so:)
> | > 
> | > Being able to repeatably build images based on a minimal core image
> | > is certainly headed in the right direction, but we still have a
> | > ways to go on the tools front ...
> | > 
> | > Dale
> | 
> | I want to respectfully disagree (and I even don't understand some of
> | your remarks, or the underlying implications, given your excellent
> | work on Metacello and some much other contributions to Smalltalk).
> | 
> | Yes, the very old way of passing images around was arcane and did not
> | scale (I did this too in the 80'ies early 90'ies).
> | 
> | But today, with Monticello and Metacello things are quite different,
> | not perfect but totally acceptable.
> | 
> | When building Smalltalk applications I am using code written by
> | hundreds of people during tens of years, this works out very well.
> | 
> | In traditional file bases language like Java or C using a traditional
> | SCM, you will immediately hit problems when even a couple of people
> | work on parts of code that are closely related. Merging, branching,
> | solving conflicts there is no different than with Monticello, IMHO.
> | 
> | Organizing big teams is plain hard, in any language. Clear
> | separations/responsabilities/interfaces are the only answer.
> | 
> | Sven
> | 
> | 
> | 
> | 
> 

James Robertson
http://www.jarober.com
jarober at gmail.com