Agile/XP book now freely available

[kent]

Hi,

Agile Development, in particular, eXtreme Programming (XP), has been
gaining a lot of momentum because it can effectively address the
problems plaguing software development.

In 2002, we, the Macau Productivity and Technology Center (CPTTM),
started to hold courses on XP and OO design to teach the skills in
agile development. At the beginning, we hired a well known software
training and consulting company in US to teach. While the instructor
was very professional and instructive and the feedbacks from the
students were very good, the students didn't acquire the skills taught.
Later we switched to use local instructors, the feedbacks results were
worse and the students didn't acquire the skills either.

We knew that it was because the concepts involved were abstract and it
needed far more exercises for the students to practice in the courses.
Therefore, we decided to develop our own training materials. In
particular, we selected only the essential skills in agile development,
ignoring those useful but non-essential skills. Then we explained these
skills in terms of examples and added a lot of real world examples as
exercises. After adopting this set of materials, with exactly the same
instructor, the new students really acquired the skills taught and the
feedbacks soared instantly.

Now we have organized the training materials into a book: Essential
Skills for Agile Development.

This book covers the essential skills in: OO design, Test Driven
Development (TDD), team development, planning, communication and pair
programming.

You can download it at http://www.agileskills.org/

 

[Sudsy]

Hi,

Agile Development, in particular, eXtreme Programming (XP), has been
gaining a lot of momentum because it can effectively address the
problems plaguing software development.

<snip>

It's interesting how "everything old is new again", except that it has a
new name and some additional, sometimes questionable, features. XP is not
a panacea. From an article by Martin Fowler (which can be found at
<http://www.martinfowler.com/articles/newMethodology.html> ):

"The crucial step from informal practice to a methodology occurred in the
spring of 1996. Kent was asked to review the progress of the C3 payroll
project for Chrysler. The project was being carried out in Smalltalk by
a contracting company, and was in trouble. Due to the low quality of the
code base, Kent recommended throwing out the entire code base and starting
from scratch. The project then restarted under his leadership and since
became the early flagship and training ground for XP.

The first phase of C3 was very successful and went live in early 1997. The
project continued since and ran into difficulties later, which resulted in
the canceling of further development in 1999. (which if nothing else proves
that XP is no guarantee of success.)"

Two other observations:
- One of the "features" of XP is that tests are written at the same time
as the code. Show me a good Java programmer who /doesn't/ include a main
method in every class to permit convenient unit testing! It's just
(un)common sense.
- The "pair programming" concept is completely alien. I know that I'd go
completely nuts if I wasn't allowed to /touch/ the keyboard while
"programming". After doing this for so many years, there's a flow between
my brain and my fingers on the keyboard. Interrupt that and it's likely
that my productivity will not so much fall as plummet.

 

[xarax]

<snip>

It's interesting how "everything old is new again", except that it has a
new name and some additional, sometimes questionable, features. XP is not
a panacea. From an article by Martin Fowler (which can be found at
<http://www.martinfowler.com/articles/newMethodology.html> ):

"The crucial step from informal practice to a methodology occurred in the
spring of 1996. Kent was asked to review the progress of the C3 payroll
project for Chrysler. The project was being carried out in Smalltalk by
a contracting company, and was in trouble. Due to the low quality of the
code base, Kent recommended throwing out the entire code base and starting
from scratch. The project then restarted under his leadership and since
became the early flagship and training ground for XP.

The first phase of C3 was very successful and went live in early 1997. The
project continued since and ran into difficulties later, which resulted in
the canceling of further development in 1999. (which if nothing else proves
that XP is no guarantee of success.)"

Two other observations:
- One of the "features" of XP is that tests are written at the same time
as the code. Show me a good Java programmer who /doesn't/ include a main
method in every class to permit convenient unit testing! It's just
(un)common sense.
- The "pair programming" concept is completely alien. I know that I'd go
completely nuts if I wasn't allowed to /touch/ the keyboard while
"programming". After doing this for so many years, there's a flow between
my brain and my fingers on the keyboard. Interrupt that and it's likely
that my productivity will not so much fall as plummet.

The infamous "stream of consciousness" style of programming
is still alive and well, unfortunately. Writing code at the
moment it is conceived in the brain is a recipe for poor
design and bad implementation. Changing the design is faster
and less expensive than changing the written code.

 

[Sudsy]

xarax wrote:

The infamous "stream of consciousness" style of programming
is still alive and well, unfortunately. Writing code at the
moment it is conceived in the brain is a recipe for poor
design and bad implementation. Changing the design is faster
and less expensive than changing the written code.

<snip>

So you "design" each line of code in a method before sitting
down to type it in? Seriously, I know what my classes need to
provide before writing in Java. Other languages (doing a driver
in C for a Linux webcam right now) require different approaches.
And having different approaches available is great!
You just have to appreciate that there's no such thing as "one
size fits all" in the methodology department.

 

[kjc]

I'm agreement with Sudy here. Front loading an project with too much
design is a recipe for failure. I have used the XP approach since before
it was called "XP". Besides, as they say "the devil is in the details".
The XP method provides for getting the "devil" out of the way sooner
rather than later. Which, in my opinion is ALWAYS a good thing.

The other thing is XP is client/business driven. Which means that on
Fridays before the weekend, the people that write our checks, go home
with a smile on their faces after seeing something that is working and
demonstrable, sooner rather than later. Which, again, in my opinion,
is ALWAYS a good thing.

 

[kent]

It's interesting how "everything old is new again", except that it has a
new name and some additional, sometimes questionable, features. XP is not
a panacea. From an article by Martin Fowler (which can be found at
<http://www.martinfowler.com/articles/newMethodology.html> ):

[...]

The first phase of C3 was very successful and went live in early 1997. The
project continued since and ran into difficulties later, which resulted in
the canceling of further development in 1999. (which if nothing else proves
that XP is no guarantee of success.)"

I agree that XP is no guarantee of success. However, I do believe
that XP is more effective than the way many people have been
developing software.

Two other observations:
- One of the "features" of XP is that tests are written at the same time
as the code. Show me a good Java programmer who /doesn't/ include a main
method in every class to permit convenient unit testing! It's just
(un)common sense.

Are those test automated? In addition, TDD is different in that
we switch coding and testing maybe several times in one minute.
This is certainly pretty new to most people.

- The "pair programming" concept is completely alien. I know that I'd go
completely nuts if I wasn't allowed to /touch/ the keyboard while
"programming". After doing this for so many years, there's a flow between
my brain and my fingers on the keyboard. Interrupt that and it's likely
that my productivity will not so much fall as plummet.

Pair programming does allow you to touch the keyboard. If you'd
like to express something to your partner and you find that
doing it by code is the best way, then you're always encouraged
to grab the keyboard and show him.

 

[Andrea Desole]

I'm agreement with Sudy here. Front loading an project with too much
design is a recipe for failure. I have used the XP approach since before
it was called "XP". Besides, as they say "the devil is in the details".
The XP method provides for getting the "devil" out of the way sooner
rather than later. Which, in my opinion is ALWAYS a good thing.

too much design is a recipe for failure, because you waste a lot of time
in details you would deal better with if you wrote the code. Design is
for the overview, not for the lines of code.
On the other side, too little design is also (or can be) a recipe for
failure, because you can work out bigger things faster when you think
about them than when you implement them.
How much you should design and how much you should code, it depends. For
bigger projects you should probably design more, and plan more, because
the time you spend changing a lot of code is a lot of time. This is the
reason why XP is not good for big projects.

The other thing is XP is client/business driven. Which means that on
Fridays before the weekend, the people that write our checks, go home
with a smile on their faces after seeing something that is working and
demonstrable, sooner rather than later. Which, again, in my opinion,
is ALWAYS a good thing.

also true. But it also happens that, to make those people happy, people
do terrible things, like massive copy and paste and hardcoding. Which is
never a good thing

The bottom line is, as Sudsy said, there's no such thing as "one
size fits all"

By the way, shouldn't this be for the software-eng newsgroup?