Berin Loritsch wrote: > > * Test driven development. Write tests before code. That way you know your > requirements are measurable, and that code needs to be written (you might > find your current system can handle the new requirement without change).
I'm not an Avalon developer, but I've written much software and simply don't buy this one. Put the time used for writing tests into writing docs and the code will be way better - plus you have docs :) > * No attachment to specific methodologies. Just because our idea works today > doesn't mean it will tomorrow. (Remember the points from no big design up > front). Don't fight tooth and nail for a way of doing things--more than > likely it will be replaced with something that works better later. Does that include the XP principles? :) BTW, you forgot one XP principle, which states that programmers work in teams of two and take turns writing software and supervising the software writer. Not sure how that's supposed to work in OpenSource, though :) The other XP principles you mentioned are all good, but test-driven development is a decoy. You can never catch the hard-to-find bugs and simply fixing the trivial bugs, when they occur, is much faster than writing formalized tests for them. There's a Dilbert cartoon, which goes so: Boss: "We have to come up with a strategic plan that will justify the resources spent in fixing that bug." Dilbert: "Oh, I can fix that in 10 seconds... clackedy-clack... Ok, done!" Boss: "Good work, now all we need is that plan." The moral is: why worry about formalizing trivialities, just get the job done. And you'll never succeed in formalizing non-trivialities, i.e. writing tests for hairy bugs. cheers, Ulrich --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
