-------- Prvotno sporoÄilo -------- Zadeva: Re: [vwnc] Smalltalk for small projects only? Datum: Mon, 30 Jan 2012 19:27:31 +0000 Od: Niall Ross <niallfr@btinternet.com> Dear Janko, (tried to send this to Pharo and squeak mailing lists as well as well as vwnc and you - got a hiccough; trying again just to vwnc and you). The largest Smalltalk project I've experienced was Kapital. They were approaching 70 developers in 4 locations in 2005 and IIUC are larger now. They use an in-house process based on Envy. Frequent rebuilding of images is forced by aging of Envy repositories, properly committed stuff being copied over. Thus developers are obliged to use correct process or lose code. I described the process briefly in a secondary talk (not my main one) at ESUG 2004, and Jan Monclair gave more recent info at ESUG 2008 and ESUG 2009 (see my reports on the ESUG website). A developer I knew there had practical experience of a rival's attempt to replicate their achievement in Java, using comparable resources, that crashed and burned. I've worked in two teams of 15 - 20 developers (one on a single site, one at two sites), each of which were verifiably matching systems maintained by ~100 developers in rivals. These were both in the insurance domain. In one of these, Envy-based, each developer rebuilt their image each day - the process took quite a few minutes but was valuable. In the other, images were eternal (yes, I do mean that!); it would take a long time to describe their process and even longer to convince readers that, contrary to what I at first thought and what most of you will think, it was a viable development process. All the other Smalltalk teams I've worked in, prior to coming to Cincom, were in single figures and used Store or Envy. One of them was verifiably rivalling a sytem of 10s of people in another language. Conclusions: 1) As your Smalltalk project gets large, you will need to put process and tools in place on top of what Envy, or Store, or, as Dale says, Monticello and Metacello, give you out-of-the-box at the moment. (It is news to me if Java projects of 200 people do not find the same, but I defer to those with more - which means any - experience of being in a 200-person Java project to correct me if that is not so - or is less so in some important respect.) It would be good if Smalltalk projects that find themselves growing into this area could get a tool/add-on that conveyed existing experience and solutions instead of having to re-roll their own superstructure on existing tools. (In Cincom, we are attempting to use our own development-process and build-process-improvement work to achieve this.) 2) Combining Kapital experience with the ratio one can justify between 'Smalltalk developers needed to do' and 'Java developers needed to do', persuades me that there is no limit on the complexity of problem Smalltalk can attack relative to its rivals. 3) I agree with Dale that making the minumum image smaller is the way to go. (Again, we wish to do this in VW; as always, such efforts progress slowly in background while we meet immediate requirements.) Yours faithfully Niall Ross -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si