[Insight-developers] Observations on the ITKv4 Software Process

[Bill Lorensen]

Folks,

I'm sure you are having a productive and stimulating meeting in
Iowa. I always looked forward to the ITK Developers' meetings. Not
only for the technical exchanges but also for social interactions.

As contractors, you know that ITKv4 is a challenging project. Lots of
new things: new technology to develop, new people to work with,
new software practices to develop/learn. All in a very short period.

The situation is not much different from the original ITK developement
effort. Actually, I believe the original project was even more
challenging. But that's another story.

Yesterday
---------
In 1999, NLM and the ITK contractors started to create the ITK we have
today. In addition to building a powerful segmentation and
registration toolkit, we defined, refined and adopted a software
development strategy based on Extreme Programming and Software
Quality. in 1999, for many of the contractors, this was a new, scary
and confusing environment. We used open source tools like cvs for
revision control but had to develop CMake for cross platform
development and Dart/CDash for software quality control. These tools
were developed in concert with the ITK architecture, algorithms and
applications. This was not an easy process, but in the end, most of us
bought into the process and became advocates for it.

Today
-----
Setting aside the algorithm and technology aspects of ITKv4, which,
for the customers, NLM and the ITK community is probably the most
important part of the effort, I have a few comments on the software
process.

For ITKv4, we decided to use git as a source code management system
and gerrit as a review mechanism. These decisions were made based on
software process deficiencies that we noticed in the first 10 years of
ITK development. For example, community contribution to new
algorithms/code and code walk throughs were not well supported by the
old process. As an aside, for the duration of the ITK contract, Jim
and I would review ITK contractor code every morning on a large, multi
window display screen. When Jim or I wrote new code, we always reviewed
the code together. Other contractors adopted (some did not) similar
practices.

Observations
------------
Now, finally, some comments on the state of the software process for
ITKv4. (I repeat some of these comments from a recent e-mail exchange
on the itk developers mailing list).

Some high level comments:
  git is good, but different than cvs and much more flexible (complex).
  gerrit is good, and something we never had and less complex than git

My impression of the current state of the ITK software process:
After almost 5 months of ITKv4 development, just a few of us are on
the bleeding edge (we shed our blood for our fellow developers). We
are the guinea pigs. We have a gut feeling that git and gerrit are the
way to go. We are also process geeks. Some of us are still algorithm
developers or do real research.Early on we had problems with both git
and gerrit. The gerrit learning curve is not too bad (but still
there). git still challenges us on a regular basis. I, for one, have
come up with a workflow that I understand. And I have figured out how
to recover from some, but not all, git problems.  But we generally
recognize that these software engineering processes are valuable.

Soon, many folks with different skills and interests will be
contributing to ITKv4. Some of them will be more focussed on
algorithms and research. If they become frustrated with our processes
we will have real problems. These folks will not be able to meet their
deliverables for their ITK contracts. And the process could be the
problem (excuse).

So, if the ITK process geeks are having problems, you "ain't seen
nothing yet.

Neither git nor gerrit is simple. (nor were make, sccs, cvs, svn,
cmake, dart, cdash...)

To quote an anonymous friend with many years of software development
experience:
 "It seems oddly incongruous that at the same time we are wrestling
 with how complicated "Simple ITK" can be allowed to be, we are
 adopting a system for version control that takes an advanced degree
 to explain"

And another friend, who I consider an early adopter of software technology:
 "I'm familiar with distributed revision control systems (mercurial,
 not git), but the growing complexity of the git-based work flow is
 essentially impossible for me to follow through this
 conversation. Developers just can't be required to be experts in the
 implementation details of git/gerrit to do straightforward things. As
 you said, cs-oriented geeks can figure things out, but that may pose
 its own set of issues for all but a few ("is that what you're really
 being paid to do on this project?").
 Maybe vtk and itk really do require this level of complexity, but
 holy smokes....

Challenges
----------
Make the complicated process seem simple
  Documentation: Consistent, well organized documentation on using git
  and gerrit. Currently, we have multiple, sometimes conflicting pages
  describing how to do the same thing.

  Aliases: The git/gerrit experts have provided useful git aliases to
  assure consistent and idiot proof use of some git/gerrit processes.

  KISS: Do not adopt complicated processes for things that already
  work. For example, a complicated process for adding/updating test
  baseline images

Summary
-------

We are on track to use state-of-the-art software tools to make the ITKv4
software development process more robust and productive. But there is
a high learning curve (higher than ITKv0-3). Our challenge is to make
it seem easier than it is.

Regards,

Bill