Re: [Boost-users] What's happened to Ryppl?

Subject: Re: [Boost-users] What's happened to Ryppl?
From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2011-01-28 10:59:38

>From: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Eric J. Holtman
>Sent: January-28-11 8:56 AM
>To: boost-users_at_[hidden]
>Subject: Re: [Boost-users] What's happened to Ryppl?
>
>>On 1/28/2011 7:46 AM, Edward Diener wrote:
>
> 
>> I do not follow why these are advantages. I can make any changes 
>> locally for files using SVN without having to have a connection to the 
>> SVN server. Your phrase "incremental local commits" sounds like more 
>> Git rhetoric to me. How does this differ from just changing files 
>> locally under SVN ?
>> 
>
>
>You can check in while you work.   Which means you
>don't have to worry about "breaking the build", or anything like that.
>
>Write some code, test it, seems to work, check it in.  Come back after
lunch, discover it's fubar, revert.  Lather, rinse repeat.

This may be adequate IF you're working alone and if you have all the time in
the world, but it will become an unmaintainable nightmare when the number of
programmers contributing to the project increases significantly and as time
pressures grow.  Imagine the chaos that would result from this if you had a
dozen programmers doing this independantly to the same codebase.  

And actually, I don't care which version control software is in use, as long
as it is used well.  Each product has strengths and weaknesses, and thus
some will have strong preferences for thos eproducts that most closely
reflect their own tastes.  Unless a given product's developers are
blithering idiots, a rational argument can be made for using their product.
And then, the final decision is made either by the team, democratically, or
autocratically by a project manager or team lead.  And if a change is to be
made, the onus is on the proponents of the change to first prove the change
is wise and then to provide/plan the means of making the change.  It is
folly to decide to make a change, even if to a demonstrably superior
product, if there are insufficient resources (including time) to get it
done; especially if the existing setup is working adequately.  A practical
rogrammer, while having preferences for certain tools over others, will be
flexible enough to work with whatever is in place for a project to which he
has been assigned to contribute (in a commercial setting) or to which he
wishes to contribute in other cases.

As one responsible for a small development team, and who has to keep junior
and intermediate programmers on track, this notion of " Write some code,
test it, seems to work, check it in.  Come back after lunch, discover it's
fubar, revert.  Lather, rinse repeat" scares me.  When you're dealing with a
commercial app that has half a million lines of code, or more, it is just
too easy to break things (there are practical and commercial reasons for
rational modularization as results in object oriented programming, as well
as proper management/design of compilation units, &c.).

I would prefer a model where there is a highly developed suite of test code
(actually, I find it is often best if one begins with the tests first - but
sometimes that is not practical), unit tests, integration tests and
usability tests, and nothing gets checked in unless the code base plus the
new code not only compiles, but the developer can show that with his
implemented changes, the system still passes all tests.  And note, his new
code must come with a test suite of its own, and must pass through a code
review before we accept that his tests are adequate and thus before he can
run the full test suite.  With this model, it happens that new code stresses
existing code in initially unexpected ways, revealing previously undetected
bugs.  But at the same time, it makes it less likely that new code will
introduce a significant number of new bugs when it is approved to be
commited to the codebase.  And this means that while the new code that is
approved to be commited will have the same number of bugs per thousand lines
of code that most other programmers experience in their code, the number of
bugs per thousand lines of code can only decrease.  And where the version
control software in place does not support a given detail of this model (and
note, this model can be made to work even with something as primitive as RCS
or CVS), we need a manual process to make it work.  In my practice, no
member of my team commits anything until we know it works with everything
already in the repository - no exceptions.  This means that sometimes a
programmer will work on an assigned task for days, or even a week, without
commiting changes to the repository.  This actually help productivity rates
since we waste much less time tracking down bugs that had been introduced
weeks or months earlier, and then fixing them along with new code that
unwittingly depended on code that was broken.  Until I learned this, I
occassionallt saw situations where weeks or months worth of work had to be
discarded because of dependancies within code along with months old code
that had subtle bugs (but then, I have been doing this for 30+ years in a
number of different languages, and the commercial practice of software
development wasn't then what it is now).

Cheers

Ted