[ajug-members] Which Source Version Control System do you pre fer?

Fri Dec 2 10:49:49 EST 2005

This is actually one of the more interesting debates I've seen come
through this list in a while.

First off I agree for the most part with Paul, but I wonder how much
my reasoning for that is the type of environments I come from.  The
majority of my experience is working with large teams 50+ developers
on comercial shrink wrapped software, with a mature codebase.  We
build one version of our software that will not be customized, that
must work for all of our clients, of which there are 100's.

Now someone asked what makes a change unnecessary.  Well anything that
doesn't result in additional revenue or long term cost reduction to
the development team.  Some of the examples you gave were very good
examples of long term cost reduction meassures.  Making the code more
maintainable and refactorable reduces future development cost, but
over what time frame will those cost be recouped.  What will my ROI be
for those code change?  If I can't build a business case that says
chaning this code will increase my profits then it shouldn't be
changed.  My ideal code base is one that I can continue to sell with
out making any changes what so ever.

Now thats what worked for me in the past, bu now I work for a small
start up company.  I have a only a few developers and a blank slate of
code base.  I want to get things off to a rapid start and I need to
get features into the product quickly so we can start building a
revenue stream.  My requirements are very fussy as we are still
exploring the market place, so refactorability is key.  In this
environment the methods I explained above don't apply as much.

Now what if I work in an internal IT department or Custom software
shop.  I have no idea what would work well here as I have no
experience but I imagine they would have their own constraints that
would shape their development process.

Just my 2 cents

On 12/2/05, Christopher Gardner <chris.r.gardner at gmail.com> wrote:
> Assuming you have a good set of unit tests in place, if you see the
> opportunity to improve the code, you should do so, lest your software
> fall into entropy.  Granted, you may have to ask your project
> management for a 1 week refactoring iteration for big refactorings.
> In fact, it might be a good idea to schedule a cleanup iteration from
> the get-go (say after 3 or 4 iterations).
>
> What would be an unnecessary change to code?  Changing a method name?
> Breaking a 1000 line method up into a few composed methods?  Giving a
> class a single responsibility by moving its errant code to another
> class?  Such things make code more maintainable, amenable to change,
> and may even lower the likelihood of defects.
>
> You mention that it is always dangerous to change working code.  Isn't
> it more dangerous not to refactor code when it needs it?  Changing the
> name of a class to something more appropriate for the domain, for
> example, while potentially far reaching, may clarify an important
> concept for exisiting and new developers.
>
> On 12/2/05, Justin Meads <jmeads at adelphia.net> wrote:
> > Actually we do it to discourage any unnecessary changes to the code.
> > It is always dangerous to change working code even if you have unit
> > tests (it is just less dangerous with tests).  Remember Martin Fowler
> > has a big section in his book on when not to refactor.  That being
> > said, we strongly encourage the developers on my team to refactor the
> > code if it is related to a feature or defect they are working.  We
> > just don't want them randomly "improving the code".  It would be hard
> > for us to explain to our customer why we introduced a new bug in a
> > section of the application that shouldn't have changed.
> >
> > We also use the defect information to perform code reviews.  We can
> > sit down in a small group and look at all of the code that was
> > changed in order to implement a given feature or defect.
> >
> > -Justin
> >
> > On Dec 2, 2005, at 12:32 AM, Eric Friedman wrote:
> >
> > > I also wondered why one would want to tie every check-in to a
> > > defect. I think Paul made some good points. But I think this would
> > > discourage refactorings. Maybe it depends on the maturity of the
> > > product and the discipline of the developers.
> > >
> > > Couldn't you get most of this information when needed from a report
> > > or a diff? I am not that familiar with Subversion. (But I will be.
> > > My team will start using it next week. I like the timeliness of the
> > > question and am happy to hear that the Subversion users are happy
> > > with it.)
> > >
> > > Regards,
> > >
> > > Eric
> > >
> > > At 09:03 PM 12/1/2005, you wrote:
> > >> IMHO, a comment in the code is not enough information to track
> > >> anything larger than a trivial change.
> > >>
> > >> Using your example, simply changing a method name (very easy in
> > >> Eclipse) can potentially have a far reaching impact: Any code that
> > >> calls that method, bean-mapping code, configuration code, database
> > >> schema, etc. I find it difficult enough to keep track of changes I
> > >> personally made a month ago, much less what's going on with a
> > >> large codebase that 20 developers are working on.
> > >>
> > >> A defect report provides a way to tie changes across the codebase
> > >> to a single point: The code changed, the reason changed, how to
> > >> test it, where to find more documentation. Further, a bug report
> > >> tied to a check-in tied to a release gives you a point to go back
> > >> to if (knock on wood) you should happen to make a mistake in the
> > >> refactor. I won't speak for anyone else, but I have made plenty of
> > >> stupid mistakes during "simple" refactors.
> > >>
> > >> Do I really think that I need a bug report to change the name of a
> > >> private method that is only called one place? No. But how often
> > >> does that really happen? IMHO, what really happens is that
> > >> developers want to get in there and write code and that the impact
> > >> and complexity of some "simple" changes can be much greater than
> > >> originally expected. Writing a bug report first (I think) is
> > >> similar to the XP practice of writing the test case first: What do
> > >> you want it to do? A good question to ask before writing the code.
> > >>
> > >> Just MHO, based on years of screw-ups.
> > >>
> > >> Christopher Gardner wrote:
> > >>> Why is it important to track have to tag every checkin with a
> > >>> specific
> > >>> defect or feature task?
> > >>> On 12/1/05, Christopher R. Gardner <chris.r.gardner at gmail.com>
> > >>> wrote:
> > >>>> Seems like waste to me.
> > >>>>
> > >>>> ----- Original Message -----
> > >>>> From: "Paul Philion" <philion at acmerocket.com>
> > >>>> To: "General AJUG membership forum (100-200 messages/month)"
> > >>>> <ajug-members at ajug.org>
> > >>>> Sent: Thursday, December 01, 2005 7:21 PM
> > >>>> Subject: Re: [ajug-members] Which Source Version Control System
> > >>>> do you pre
> > >>>> fer?
> > >>>>
> > >>>>
> > >>>>> Christopher Gardner wrote:
> > >>>>>> How do you check in code if you have to do a refactoring that has
> > >>>>>> nothing to do with a requirement or defect (e.g., renaming a
> > >>>>>> poorly
> > >>>>>> named class, changing a method name, etc.)?
> > >>>>> Write a defect to track the refactor.
> > >> _______________________________________________
> > >> ajug-members mailing list
> > >> ajug-members at ajug.org
> > >> http://www.ajug.org/mailman/listinfo/ajug-members
> > >
> > >
> > > _______________________________________________
> > > ajug-members mailing list
> > > ajug-members at ajug.org
> > > http://www.ajug.org/mailman/listinfo/ajug-members
> >
> > _______________________________________________
> > ajug-members mailing list
> > ajug-members at ajug.org
> > http://www.ajug.org/mailman/listinfo/ajug-members
> >
>
> _______________________________________________
> ajug-members mailing list
> ajug-members at ajug.org
> http://www.ajug.org/mailman/listinfo/ajug-members
>