You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/07/28 21:22:50 UTC
[RT] Adopting XP Practices in Avalon
I personally would like to start adopting XP practices with Avalon. I believe
that it fits the open source development style very well. The thing is we have
several challenges ahead of us to get it done. Not the least of which is the
change in mental framework that we have to go through.
We do not all need to come to agreement that this is the way to go for working
with Avalon code, but there are some lessons to be learned from it. I think
things will go smoother once we come to grips with these lessons. The
observations are mine, so feel free to take them with a grain of salt (please
refrain from comments to that effect... ;P )
Anyway XP practices include:
* 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).
* Do the easiest thing to satisfy a requirement. Why waste time and effort
properly implementing a finite stage machine when a couple of simple if/else
statements will do the job?
* Refactor mercilessly. When the if/else statements are no longer the easiest
thing, they should be replaced with something that is. As we refactor
mercilessly we learn code "smell" and can attack systemic problems more
easily.
* No big design up front. While we have a general requirement, we don't have
all the information we need at the beginning to properly specify it. Don't.
As we find something that works, we can specify it then. In general, hard
requirements should be avoided.
* 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.
So what does this mean as far as it affects us?
* We will have better test coverage (for the essential stuff we are ok).
* We will have fewer hard positions. What is easiest for us here is to
identify interface/implemenation. We should take advantage of that.
* We will spend less time arguing about the name of something and more time
doing. (more fun).
That said, I think that some of us are so ingrained with the big design up
front mentality that they don't realize how much it is impacting Avalon. I
probably fall into this category myself. It isn't easy to allow designs to
evolve. The more practice we have at it the easier it will become. We also
have some specs that need to be supported. We will need to do that for as
long as Avalon 4.0 is supported.
Let's start working towards middle ground much sooner, which probably means
that those points of contention need to be addressed uniquely. For instance,
address some issues can be solved by applying our SoC design pattern.
Implementation is far less important than interface. Interface should start
simple and only be expanded when it is absolutely necessary.
Remember, let's do the simplest thing to resolve an issue.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Adopting XP Practices in Avalon
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
Berin,
> I personally would like to start adopting XP practices with Avalon.
+1
--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Adopting XP Practices in Avalon
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
Niclas,
>People who hasn't been infected will always criticize the "Test driven"
>principle of XP. It is an earth shattering experience to become infected.
>
>
Could not agree more.
>Finally, the Unit testing does NOT REPLACE functional tests, which Kent
>Beck et al, unfortunately does not cover very well in literature, but I
>think can leverage the XP model independently of the Developer side of the
>
>
Gets closer and closer, at least for functional acceptance tests.
http://marathonman.sourceforge.net/ , http://fit.c2.com/
The unit test framework writers get more and more brave with boundaries.
- Paul
--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Adopting XP Practices in Avalon
Posted by Niclas Hedhman <ni...@hedhman.org>.
Berin Loritsch wrote:
> Ulrich Mayring wrote:
>> 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.
Also, the "Document Style" also assumes "slow evolution". The XP testcases
are always in-sync with the code evolution, since "Continous Integration"
requires it to be so.
I used to be more "test hostile" and "documentation friendly", but have
recently changed, as not only does the testcases improve quality and
fasten the coding, but also drives the Use-Case design issues.
People who hasn't been infected will always criticize the "Test driven"
principle of XP. It is an earth shattering experience to become infected.
Finally, the Unit testing does NOT REPLACE functional tests, which Kent
Beck et al, unfortunately does not cover very well in literature, but I
think can leverage the XP model independently of the Developer side of the
XP equation.
Test Infected...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Adopting XP Practices in Avalon
Posted by Berin Loritsch <bl...@apache.org>.
Ulrich Mayring wrote:
> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Adopting XP Practices in Avalon
Posted by pe...@realityforge.org.
From: "Ulrich Mayring" <ul...@mayring.de>
> 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.
...
> 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.
I don't think you understand the purpose behind TDD. While it is true
that TDD can be used to generate tests for trivial and non trivial code
paths I am not sure thats the primary reason why it is so useful.
One of the central tenets of Agile-style methodologies (of which XP is
just one) is to keep the code base agile and not do any large up front
design - just do enough to get to next step. The problem with this is
that people are not forced to think about even minor design issues like
the API design.
TDD forces developers to think about these issues. You effectively design
and define the contract/API for the functionality with the unit tests and
from
this you have a stub of your final implementation class. So IMHO the best
thing TDD does is force developers to think about the minimal design issues.
TDD often highlights many issues and corrects many "design" bugs before
you write a single line of code.
Traditional development process would have an extensive specification
process to determine the APIs/Contracts of interfaces - XP does not have
this and TDD compensates for this loss. As much as process is a dirty word
to Agile peeps, TDD is effectively a process to ensure a minimal level of
design and thought has gone into the system.
Another significant advantage of TDD is that it tends to produce code that
is highly testable. This is very desirable - even if the code is never
actually
unit tested. The reason is that testable code is often well factored, simple
and much more easier to maintain due to its focus.
The fact that TDD produces extensive unit tests is great and even essential
to Agile to ensure reliability in face of massive refactoring. However I
don't
think this is as important as the above "features" of TDD.
Once people adopt TDD I have found that it actually decreases the time to
develope. Mainly as the people
a) think about the code and the contract
b) write code that is focused/testable
c) have unit tests to make sure that the implementation matches their
assumptions
It also helps later in the development cycle by reducing chance of
incompatible changes. No unit tests should be an effort to write -
even for trivial bugs. In fact the unit tests should be the fastest way
to locate bugs (trivial or not). If this is not the case then you probably
did not develope code using TDD.
TDD is no magic bullet (in fact it ofen makes people think too "locally"
when
they should be thinking "globally") but I would not dismiss it if I were
you.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Adopting XP Practices in Avalon
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Ulrich,
I find some XP practices a bit extreme too... but I tend to agree
with the test driven bit.
The "Pragmatic Programmer" line looks more down to Earth than the
XP line and they DO put a lot of emphasis on testing too. For a very
interesting read on the subject, take a look at:
http://www.artima.com/intv/plain.html
This is the last of a series of 10 small interviews. I send you the
URL to the last because this one has a list of the URLs of all the
others. The complete list of interviews at Artima can be found at
http://www.artima.com/intv/
Some other (very) interesting "Pragmatic Programmer" stuff at:
http://www.pragmaticprogrammer.com/cgi-local/pragprog?HomePage
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: news [mailto:news@main.gmane.org]On Behalf Of Ulrich Mayring
> Sent: segunda-feira, 28 de Julho de 2003 23:26
> To: dev@avalon.apache.org
> Subject: Re: [RT] Adopting XP Practices in Avalon
>
>
> Berin Loritsch wrote:
>
>...
>
> > * 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Adopting XP Practices in Avalon
Posted by Ulrich Mayring <ul...@mayring.de>.
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org