Code integration

[John Walker <acad!throop!kelvin>]

>>From various recent messages I've seen on xanadu!us, it looks like
there's quite a bit of wheel-spinning going on when new versions
are posted and people discover that changes they (or others)
have submitted that were present in earlier versions have been
dropped.

This is a very frustrating experience, and in the absence of a software
tool to prevent it (a tool I've never encountered, although with Xanadu...)
it's almost inevitable, particularly when several people are working on
sideline versions of the product and contributing changes on a rapid
basis.

We've fought this problem at Autodesk since inception (and in earlier
lives in similar environments), and we've ended up with a technique which
is essentially managerial rather than technical (we have a toolset to aid
in the process, but it's specific to conventional languages such as C and
isn't the essential piece in any case).

The way we do it is to designate, for every product under development,
"The Integrator".  This individual, always a senior software
developer actively working on the product who shoulders this
responsibility in addition to his regular work, maintains the master
source code copy of the product and personally reviews all code
submissions (which are made in a stylised form to aid this task, but
that's not really relevant here), and installs the changes, finally
building the updated product, verifying that it runs the regression tests,
then handing it over to the build group for verification that it builds
from scratch and, if so, eventual distribution to all the other developers.

The essential point, one that we've learned through painful experience,
is that integration is not a job for a junior person.  If you have a person
with encylopedic knowledge of the product and how changes in one part may
affect code in others, and that person has the temperment to do the job,
that's the ideal candidate for Integrator.

Doing code integration is time-consuming, preparing code submissions for
an integrator is irritating, and waiting for official builds is frustrating.
My experience has been than compared to the time lost due to accidental
regressions which each developer painfully debugs on his own, and the
morale cost of seeing an upward ratchet of product development be replaced
by more of a random walk, the price is well worth paying.  With regard to
scaling, I apply formal integration methodology to new product development
efforts in which I'm involved even if only two developers are contributing
code (AutoSketch, AutoShade, CA Lab), and I volunteer as integrator on such
projects.

The essential cultural element is that being named Integrator for a project
carries a high degree of prestige--the Integrator is the guardian at the
gate; he has ultimate authority to reject and return any code submission
that fails to meet the standards of documentation, style, and testing.
If the Chief Engineer decides what is to be done, the Integrator decides
how well.

I'm just passing on this information in case it may be of use; it was far
from obvious to us, and the way we apply this methodology is the result of
lengthy and painful evolution which may be applicable only to our specific
environment and toolset.