• 
  

•  

  November 2002

  S	M	T	W	T	F	S
  « Oct				Dec »
  					1	2
  3	4	5	6	7	8	9
  10	11	12	13	14	15	16
  17	18	19	20	21	22	23
  24	25	26	27	28	29	30

One very interesting aspect of XP is its lack of specialisation among
the developers. Indeed, XP actively encourages a level of cross-training
that is unheard of in most other approaches. This can be very useful
because it lessens the risk that progress will be slowed as a result of
having to wait for one key individual to perform a [...]

Pair programming is a very controversial part of XP, and some
programmers are going to be unwilling to even try the practice. True,
most who try it for long enough report liking it, but there are some who
are vehemently opposed to pair programming. Although there is some
evidence that pair programming is more effective that working alone,
more studies [...]

Of all the practices of XP, Test First Development is the most counterintuitive of them all. It is probably also the most powerful of them all for promoting the necessary paradigm shift for understanding and benefiting from XP. The idea behind Test First Development is very simple: before you change the behaviour of the production [...]

The really extreme part of XP is the way it insists on incremental
development. XP attempts to minimize the elapsed time from when a user
describes some functionality in detail to when that functionality is
ready for the user to test and use. The speed at which the team can turn
a conversation about a feature into tested, running [...]

Success with the planning game relies on a shift in organizational
behaviour so that the organization accepts the estimates given by the
programmers. How likely is it that command and control-style
organizations can successfully delegate responsibility for estimating
down to the programmers? Many organizations seem to prefer the idea of
stretch targets - the idea that if the manager reduces [...]

Reinterpreting your experiences is very important in times of change. As things change, we need to see if what we learned in the past is still applicable and relevant. An example of this is the difficulty of reading source code to understand what a program is supposed to do.
Historically, this has been really hard to [...]

In the coming weeks, BeMusic will announce that we have reached an agreement for Amazon.com to provide services for the CDNOW site. As a result of this development CDNOW is ending its affiliate programs… We ask that you please remove any links to CDNOW, and all all references to the CDNOW name and logo [...]

Initially it was thought that the reason why projects were experiencing
trouble was that the programming part wasn’t being done properly. This
gave rise to the era of structured programming, which soon led to the
realization that the implementation activities were not the real cause
of project failures.
Attention then shifted upstream, and a variety of approaches were
created that sought [...]

The disease affecting projects is two headed: ignorance and haste.
Ignorance is difficult to treat because it is hard to admit to our own
ignorance. Reframing the problem as “how to be successful with only
partial knowledge” makes the conversation more palatable. By talking
about partial knowledge environments, we enable a team to talk about the
research, investigation of prior [...]

Although it is not very evident in much of the Java-centric literature
that surrounds XP, it owes most of its heritage to ideas from the
Smalltalk world. Even in the 1980s, Smalltalk had powerful, expressive
class libraries and a forgiving, flexible, powerful, and productive
development environment. The Smalltalk environment encourages developers to be fearless because it is so forgiving. [...]

keep looking »