Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!newsfeed.rice.edu!bcm.tmc.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!info.ucla.edu!psgrain!qiclab.scn.rain.com!slc.com!servio!servio!aland
From: aland@servio.slc.com (Alan Darlington)
Subject: Re: Source code/Repository management
Message-ID: <1996Jan3.201700.8984@slc.com>
Sender: news@slc.com (USENET News)
Nntp-Posting-Host: servio
Organization: GemStone Systems, Inc., Beaverton OR, USA
References: <DKD879.J5L@ritz.mordor.com>
Date: Wed, 3 Jan 1996 20:17:00 GMT
Lines: 103

At a former employer, I worked with Ward Cunningham, Paul McCullough,
and Gary Goldberg as primary developers on a financial application
written in Smalltalk.  We started in 1988, and although the original
developers have long since left (I was the last, in early 1995), it is
currently being ported to the Windows 3.1 environment by a new team in
England.

jpletzke@ritz.mordor.com (Jonathan Pletzke) writes:
<snip>
> My opinion is that:
> 1. Everything stored should be source code.

Agreed in principle, although there may be in practice things that are
not easily converted to source code.  For example, we had a test
database consisting of thousands of transactions, which was the basis
for many of our regression tests.  While these transactions could in
principle have been generated by Smalltalk methods, actually doing this
would have been impractical.

> 2. A regular re-build of the entire system from source should be done.

Doing this is critical!  We averaged 2 to 3 builds a week over most of
the project's life.  In times of fastest development (typically just
before a release :-), it would be quite common to build every day.  

I spent 3 months writing an automated builder.  I would click a button
at the end of the day and leave.  The builder would file out changed
applications, exit, start up a fresh image, file in all applications
(about an hour - we finally exceeded the 4MB limit of the sources.sml
and change.log files, which we then had to work around :-), run images
tests (such as finding calls to undefined methods and methods with no
callers), run application regression tests (these took from 10 to 20
hours at various points in the project), and create a compressed image
(i.e. browsers and extraneous system code removed - ready to send to
customers).  This saved lots of my time, and I highly recommend this
strategy for medium-sized projects and especially for larger ones!

> 3. Each developer should upgrade to the latest build after it has been
> tested.

We tried to do this, but the frequency of builds made it difficult when
individuals were doing a complex change over periods of weeks.  (At one
point, Paul worked separately for over a year on converting the
application to use an external Btrieve database.  Every few months he
would port to the latest build.  It worked, but he got really sick of
porting, and I created some new tools to help minimize his effort.)
We finally had to extend our applications to be able to report conflicts
when filing in code based on original method versions from previous builds.
The system integrator (me) would then either resolve the conflicts or send
the code back to the original developer to update to the current build.

This started in pre-ENVY days, so we had little choice but to do our own
brand of version control and system integration.  I would guess that we spent
at least a person-year over the course of several years just doing this and
generally beefing up the Smalltalk/V286 image to increase our productivity.

> 4. Test code should be written for each class and group of classes in the 
> entire system by the class authors, and executed each time before the 
> code is committed to the repository, and after the integration has been
> done.

We did this to some extent for critical classes, but most of our regression
tests were aimed at the application level.  (I.e. given a set of particular
transactions, is the value of the portfolio in the year 2000 the same
as what we had previously calculated?  This could involve hundreds of
classes, thousands of methods, and millions of calculations.)  This was
perhaps more appropriate for us, as we had lots of co-operating classes that
would have been hard to test in isolation.

The most important thing was running tests after every build.  This revealed
problems as soon as bad code was introduced, so that the developers could
fix the problems while the original changes were still fresh in their
minds.  Had we waited until the end of the release cycle to test and fix
bugs, I believe we would have added many months of programmer time to each
release.

While these regression tests could be run manually, it was rare that a
developer would actually do this before submitting changes for a build.
The length of the tests generally discouraged this, and with builds
almost daily, it was usually not a good use of time to run them manually.
I did do this sometimes myself, but only for classes that were pretty
self contained and isolated from the general application stuff.

> 5. Each class and method should be fully commented, including a class 
> method called COMMENT or NOTES that answers a string describing the class 
> and all instance variables, and a method comment in each method that 
> declares public or private, expected return value, and function of the 
> method.

In general, we flunked this.  I did pretty good myself :-), but others
tended to feel "the code is the documentation".  Actually, everybody
documented critical classes and methods.  It was just that the definition
of "critical" varied from person to person.  :-)  Also, management pressure
tended to discourage a lot of documentation, particularly written documents
on the internals.  :-(

<snip>

Brings back a lot of good memories (and some of the other kind, too).

  Hope this helps,
  Alan
    (standard disclaimer)
