Approximity blog home
870 to 879 of 903 articles

When Should We Test?   25 Sep 04
[print link all ]
Kent Beck, one of the people that invented extreme programming (XP) offers an economic model. The financial risk management community and the software development community can learn a lot from each other. Think of this article as: When should you put Risk Management into place?

Amongst other things this article tells you when best to have children :-).

Only hire people who pair?   25 Sep 04
[print link all ]
(Source: Chad Woolley posted this to the extremeprogramming-ML) Here’s an interesting experience I had when interviewing for an XP shop, and one I will definitely keep in mind in future interviews, whether I am the hirer or hiree.

As part of my interview, I was required to sit and pair program for about half an hour. We worked on an writing a unit test for an actual defect that currently existed on the project (although it could easily have been a real user story, or a contrived scenario if the project had not yet started).

I thought this was a great idea, and a great source of knowledge for both sides. I was able to show that I did indeed know how to program, write unit tests, knew my way around an IDE, had acceptable interpersonal communication skills, etc. I was also able to get a different perspective on what the team dynamics were like, which I could not have gotten from a formal interview setting.

The interesting thing is that both me and my partner (one of the interviewers) taught each other about some tools and approaches that we were not previously aware of.

Even though I didn’t get the job (the position was withdrawn), I kept in touch and became friends with the interviewer/partner, and the things we taught each other came in useful in our future development work.

This company also asked for code samples and a mini-presentation, which I also thought was a great idea for separating the wheat from the chaff.

Since I have had responsibility for helping interview, select and recommend job candidates in the past, I know for a fact that the best resume and interview performance in the world is inconclusive. You can still get a lemon, even though the lemon may be very good at piling on the BS.

From my perspective as a job candidate, I am confident in my skills and my abilities. I know that I can quickly adapt and excel in any position within my skill set. However, its very frustrating when I cannot convince the potential employer of this through only a traditional resume and interview.

In future interviews that I go for (which will hopefully only be with XP/Agile shops), I am going to suggest this as a way for the hiring company to get a better idea of my skills, knowledge and abilities, both technical and interpersonal. If I am ever part of a hiring team in the future, I will definitely propose that code samples and a pair-programming session be part of the interview process for candidates who make it to the final stages. This is admittedly very time-consuming, but probably much less net investment than being forced to live with (or try to get rid of) an employee who looked much better "on paper".

Thanks, Chad

Kaizen Events   25 Sep 04
[print link all ]
(Source: Keith Ray) Keith Ray has an interesting entry on Kaizen Events in his blog. Kaizen Event definition from Ray’s blog: The Kaizen method is a "rapid improvement process" utilizing a cross-functioning group of managers and employees working as a team to meet targets in a results-oriented focus on a predefined project area. The process may take the following steps: define the problem/opportunity, choose the best people, and correct the problem in one week or less using Kaizen tools and techniques. The ultimate goal is to significantly reduce costs, reduce lead times, reduce required inventory space, enhance workforce empowerment, eliminate waste, and focus on continuous improvement. The Kaizen process may include: new product development, robotics, total quality control, Just-in-Time, statistical quality control, labor and management relations, or other concepts.

Adapting Extreme Programming   25 Sep 04
[print link all ]
Kent Beck posted this today to the XP-mailinglist.

I’ve been thinking about the problems of applying XP to whole organizations. Turns out this is ground thoroughly covered by the lean production folks.

Here is a paper I found helpful: The premise is that every step of the transformation must pay for itself.

Getting people to understand that their problems are tractable can be hard, I’ve found. Rob Mee was talking to a guy about TDD on a gig of ours recently. "Sure, yeah, TDD is a great idea." "Why don’t you do it?" "It’ll make us go slower." "But it makes you go faster." "Yes, of course, but it’ll make us go slower." "But it’ll make you go faster" *iterate N times for annoying large N* "Okay, it makes people go faster everywhere but here."

Agile Processes Summarized   25 Sep 04
[print link all ]
(Source: Ron Jeffries and Alistair Cockburn, XP-ML)

I think that to get a group to be agile, you have to get people to do something like one of these things:

  1. Go in that room there and do all 12 XP practices until you actually do know better. (XP)
  2. Go in that room there, don’t let anyone screw with you, work on whatever you think you can get done for a month. Keep doing that until everyone is happy. (Scrum)
  3. Go in that room there, in peace love and understanding, ship software every month (*), and think about it. (Crystal Clear.)

There is a telling sameness to all of these, is there not? —> This is a wonderful summary of a summary! There’s not much to be removed (see Saint-Exupery, below). In Italian, the expresso of an espresso is called a "ristretto" (any Italians online?). This is the agile ristretto. It belongs on a Blog or something. "La perfection est atteinte non quand il ne reste rien a ajouter, mais quand il ne reste rien a enlever." (Saint-Exupery)

IT WON'T WORK HERE doesn't work here   25 Sep 04
[print link all ]
(Source: Kent Beck posted this to the XP mailinglist) This came up in a discussion of how to handle long-lead-time materials. The OP basically said,
 "I can't do all that stuff you say I should do, but how do I handle the situation ..."
  The response:
  -- IT WON'T WORK HERE doesn't work here.

XP success story: Sabre takes extreme measures   25 Sep 04
[print link all ]
(Source: Computerworld) Using extreme programming practices, Sabre Airline Solutions has reduced bugs and development times for its software products.

Sabre Airline Solutions had many years of experience with its AirFlite Profit Manager, a big modeling and forecasting package that many airlines use to wring more income out of flight schedules. Even so, Release 8 of the software was four months late in 2000 after final system testing turned up 300 bugs. The first customer found 26 more bugs in the first three days of its acceptance testing, and subsequent joint testing by Sabre and the customer uncovered an additional 200 defects.,10801,91646,00.html

Selling XP   25 Sep 04
[print link all ]
Alistair Cockburn has a very interesting paper on "The Costs and Benefits of Pair Programming". Of course Pair Programming is not the only "extreme" aspect of extreme programming but Alistair’s article contains some very interesting metrics (seems a lot less "extreme" after reading Alistair’s article).

Forth Database   25 Sep 04
[print link all ]
Richard S. Westmoreland postd this to the Forth-ML.
 In years past, we have implemented some extremely complicated databases in
 Forth.  The first was done in the mid 1970's for the company Cybek in NJ,
 and it was used in some extremely complex applications.  FORTH, Inc. also
 did some very complex databases for other companies, one of which was still
 in use last time I checked, at  That one was a
 2-dimensional database, with a huge bit matrix in the center used to
 calculate overlapping bonded indebtedness.  A few years ago my contact  there
 told me that a state agency had just spent several million $$ trying to
 replicate it using modern database tools, but the result was too large and
 too slow to be usable.

 In the late 1980's we added class-based techniques to it, which many people
 liked (although I personally preferred the earlier, simpler version).

 It's hard to describe the whole approach in a newsgroup post, though.  It
 certainly didn't resemble SQL!

Test First, by Intention   25 Sep 04
[print link all ]
A code and culture translation from the original Smalltalk to Ruby Original by Ronald Jeffries, translation by Aleksi Niemela and Dave Thomas.

In this document we show you the Ruby version of the Smalltalk code published in the pink book.


powered by RubLog
870 to 879 of 903 articles Syndicate: full/short
A unique and safe way to buy gold and silver