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? :)
Restatement: s/methodologies/software patterns/
IOW, I am not talking about RUP vs. CMM vs. XP. I am talking more about using a List vs. using a Map, vs. using something else.
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 :)
We do need to be realistic. We apply principles, not swallow the whole kit and kaboodle.
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.
I have found the opposite to be true. You can't truly fix a bug until you can prove it is there. Secondly, you can't prevent that bug from resurfacing unless you have a test case that catches it for you.
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.
Maybe so, but we can apply the 90/10 rule. If we can do it for 90%, we should do it.
Relying on documentation (esp. in open source) is far less reliable than working from tests.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
