This overhead will take work and commitment from people. How much improvement can this deliver?? 10%? 50%? 500%?
Is this advice meant only for large (>10? >100?) development groups??? The reason I am asking is that I usually work on projects with <10 developers. Things usually get done somehow regardless. (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") Chris > -------- Original Message -------- > Subject: Re: Is a ChangeLog file realistic if /lots/ of developers > adding /lots/ of changes? > From: "Thien-Thi Nguyen" <[EMAIL PROTECTED]> > Date: Thu, June 19, 2003 9:04 am > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > > [EMAIL PROTECTED]: > > If you have any advice or ways to streamline the process I would > very > much like to hear it. > > spend one hour a week as a group reading change logs (and only change > logs -- no code!) for the week preceding. discuss applicability of > changes, especially whether or not the change introduces new problems. > note change/changeback pairs. characterize and categorize changes to > determine if a larger-scope redesign is indicated (or rather, soon to > be > indicated :-). > > over time, this will streamline things because your group will be able > to recognize useless (or less than optimal) changes that should never > have been made in the first place, and thus reduce that kind of noise. > you might also develop ability to pre-emptively figure out more direct > and more robust changes to make. > > basically, to understand the code is one thing, to understand how you > change your code is the next best thing, and to understand how you > understand how you change your code is the best thing. change logs > can > help you do this. > > thi
