[ale] OT: Development practices

[Michael Hirsch]

On Wed, 9 Feb 2005 11:24:13 -0500 (EST), John Wells
<jb at sourceillustrated.com> wrote:
> Guys,
> 
> I run a development shop in Greensboro, NC.  For years before I came, the
> shop was run in a very chaotic way...no policies or
> procedures...just code and fix.

Been there.  Done that.

> I've been slowly adding processes to the mix and restructuring things, but
> now Sarbanes Oxley compliance is forcing me to pick up speed.
> 
> We've been researching different agile methodologies, Scrum in particular,
> but these methodologies leave a large gap when it comes to actual
> development processes (change control, documentation, etc). I'd like to
> find a book that outlines best practices in software development to use as
> a reference and potentially a template for our approach.  I'm really after
> more of the practical, routine things, like code reviews with sign-offs,
> user acceptance sign-offs, etc.

Scrum doesn't help a lot with that, does it?  Those are mostly
questions about development methodology and Scrum is a management
methodology.

Bob Mortin spoke at Agile Atlanta last night and had some interesting
things to say about these questions from an XP perspective.  First,
Documentation provided by XP comes in two forms.  The unit tests are a
formal documentation of the API as well as a proof of correctness in
the small.  Any team serious about quality should have close to 50% of
it's code in unit tests.

The second set of documentation should be user acceptance tests. 
These tests should be a complete specification of how the customer
expects any feature to behave.  They must be completely automated.  If
you have a web applications, then FITnesse is a great system for
writing these tests.  In some circumstances you may have to write your
own framework.

The second main point is that in XP you don't need to schedule code
reviews because all code is developed with pair programming.  There
are two pairs of eyes on the code at all times.  He claimed that the
evidence shows an order of magnitude decrease in the number of bugs in
code written this way.  My own personal experience agrees with this.

I've been in a few code reviews, but I've never been in one that
appeared to improve the code in any way--the only effect was to
familiarize some people with the code.  I think that if code review is
to be effective it needs to be scheduled early and often.  What I've
usually seen was too little and too late.  The coder felt he was done,
so was quite defensive about any criticisms.  Also, since it was late
in the cycle there was no time go back and do the sort or rework
indicated by the review.

Both of those problems would not have occurred if the review had been
1/3 of the way through, with another scheduled at the 2/3 mark, and
then a final one at completion.  But that is a lot of scheduled time
and hard to fit into the time budget in most development shops.  To do
this with all code would almost require everyone to schedule 2 hours a
day in code review.

> In other words, from soup to nuts, what are the steps that a mature
> project should go through?  What documents should be involved?  What
> sign-offs should be obtained?  What "i"'s should you dot and "t"s should
> you cross?

Have you read Schwaber's "Agile Project Management with Scrum"?  It
doesn't exactly answer your questions as is isn't that kind of book,
but it provides a frawework for thinking about such questions.

Michael