On Wed, 25 Jun 2003 [EMAIL PROTECTED] 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
