Interesante mail de experiencias reales......habla de la imagen
pequeña, viejo anhelo de Edgar.
---------- Forwarded message ----------
From: Niall Ross <
[hidden email]>
Date: 2012/1/30
Subject: Re: [vwnc] Smalltalk for small projects only?
To: Janko Mivšek <
[hidden email]>
CC: VWNC <
[hidden email]>
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
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Locked
