Re: How do you make decisions that optimize software quality?

From: lilburne (lilburne_at_godzilla.net)
Date: 08/14/04 

Date: Sat, 14 Aug 2004 17:31:19 +0100

Juhan Leemet wrote:
>
> OK, I mis-spoke. It's obviously not "any period" because the bean-counters
> would then have us only do one build at the very end = cheapest. OTOH too
> frequent can burn up resources running on a treadmill without much result.
>
> Maybe I'm thinking of larger teams which have to be structured in groups.
> In that case, I would prefer to have better defined deliverables,
> periodically submitted into the system build. I don't believe that every
> design (esp. redesign) can be completed within a day. Is that always true?
> Personally, I think for a schedule that runs out years, one could have
> full system integrations done, say, weekly. The groups themselves might do
> their own "integrations" against a stable baseline (working system) more
> frequently.
>

The project I work on is officially built and released twice
a week. IOW the codebase changes tick-tock, tick-tock,
tick-tock. The cardinal sin for a developer is to break the
toplevel. Tick-tock, tick-tock, tick-tock. Twice a month all
the libraries shared across all products are built and
released tick-tock, tick-tock, tick-tock. All the products
are rebuilt using the the new libraries, tick-tock,
tick-tock, tick-tock.

After each build the full suite of tests are run on all
applications. We have dedicated build machines for this.

That's the official cycle. Underneath that developers submit
their code changes to the test system. The system checks
integrates the individual changes builds the application and
the unit test harness, and then runs all the unit tests. At
days end the system runs all the application regression
tests on the code changes submitted that day.

Beneath that the developers build their own project version
of the application and run the application tests at the end
of each day on their work in progress. The unit tests tend
to be run all the time as they develop code.

Individual projects can take 1 day - 6 months to complete.
Though normally our developers make regular submissions of
work back into the top level.

As each new codebase is created developers can run a
"freshen project" script that brings their project up to
date with the current toplevel codebase.

> As I write this, I realize that there is no point in continuing this. If
> you're talking "XP speak" and I'm thinking concepts and terminology over
> some decades, we're probably not communicating well at all.
>

Well the XP enthusiast here have told me that because our
system is over 12 years old what we do isn't XP.

>>On the other side, daily is "white book" XP...
>>The experiance in XP shops is that they almost never have integration
>>problems, even though everyone is allowed (indeed encouraged) to change
>>anything, anywhere in the code base that they need to for the current
>>story.
>
>
> I guess I'm uncomfortable with the notion that "everyone is encouraged to
> change anything". Sounds too much like "programming with your spurs on". I
> happen to think there should be some thought given to interfaces and they
> should be protected "somewhat". If they can be defined (best) then they
> should not be changed arbitrarily, but only after consultation and
> thought. I like the idea that everyone is "deputized" to be on the lookout
> for quality issues. None of that "not my problem" kind of attitude.
> Everyone has to be engaged to deliver good product in a timely manner.
>

I have no problem with someone changing whatever code they
need to so long as:

   1) They publish what they are about to do, or speak to the
      code's guardian.
   2) That their changes do not break any of the
      application tests.
   3) That their changes do not break the integration builds.

IOW prior consultation, responsibilty for the consequencies,
and don't *** up the APIs for the other products.

If they do 1) then 2 and 3 don't usually amount to much.

>
> You're talking out of both sides of your mouth here: on the one hand
> "doesn't work isn't a crisis", but at the same time "real crime is
> breaking the build". Which is it? One could go either way. I've worked
> with "bully boy" management that "kills the messenger" (the M$ way?) and
> that has literally turned out to be a bankrupt policy!

Basically in a properly functioning system there is no
reason for a developer to break the build. The build gets
broke if you submit code without having compiled it first,
or without having ensured that all the tests pass. These are
checks that you ought to do (he says being notorious for
'breaking the build').

However, if the build is broken it is fairly obvious what
broke it, and is either simple to fix or the code change can
be backed out.

> If the schedule depended on some functionality being available on a
> certain date, and the build is busted, then obviously that functionality
> is NOT available, and that deadline has been missed. Now whether that is
> the "real deadling" or not... ask the executives and bean counters?
>

Functionality shouldn't be being submitted just before a
deadline.