RE: Is a ChangeLog file realistic if /lots/ of developers adding /lots/ of changes?

[Ronald Landheer-Cieslak]

On Wed, 25 Jun 2003 address@hidden wrote:
> This overhead will take work and commitment from people.  How much
> improvement can this deliver?? 10%? 50%? 500%?
Let me put it this way: writing Changelogs, though it does take a 
commitment, has saved me (personally) a lot of time. I've been able to 
speed up my development a lot, mostly because the debugging stage, which 
invariably follows the development stage, is a lot shorter: using the 
Changelogs, I already know what to look for and because I add a regression 
test for every bug I kill, bugs are rarely revived before a checkin.

This *does* make for big regression test suites and it *does* mean I have 
to write a Changelog for every non-trivial change (indenting is the only 
trivial change as it doesn't change the code as seen by the compiler, but 
sometimes it ends up in the Changelog anyway).

I also make sure that the Changelog only contains things related to 
eachother - i.e. I don't mix changes in a single patch. This helps finding 
related bugs (a lot).

> Is this advice meant only for large (>10? >100?) development groups???
No. I work alone most of the time - the other developers are usually users 
of what I do.

> The reason I am asking is that I usually work on projects with <10
> developers.
Makes no difference whatsoever.

> Things usually get done somehow regardless.
So do bugs.

> (I got a bad deal when I went crazy about OOP and decided to do
> everything object oriented only to discover that small projects don't
> necessarily benefit from OOP.  Sometimes OOP can even *slow down* a
> little project.  I hope this ChangeLog business is not another "OOP")
OOP is a whole other samba: it helps in architectures of big projects to 
keep the conceptually clean, but it can only slow things down on the 
performance end. There is *nothing* as fast as a big main() with as little 
as possible function calls and comparisons, but it is *hell* to maintain 
such a beast.

Changelogs should be seen as a weapon in the war against bugs - it's a 
weapon you have to keep bright & shiny in order for it to work, but it is 
a very effective one. Remember: bugs are pesky little critters that like 
to hide in plain sight and especially feed on big projects but like the 
smallers ones just as well. The only way to treat them is to kill them and 
the only way to prevent them is by meticulously coding against bugs and 
applying a bug-prevention strategy - Changelogs are part of that strategy.

Then there's always the "evolutionary" way of looking at things: 
Changelogs help track the evolution of your project and see what needs 
work. If you find you're working around a misfeature or a lack of feature 
in your project a lot, your Changelog will show that and you'll know what 
needs work. 

HTH

rlc