Approximity blog home
875 to 884 of 910 articles

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. www.computerworld.com/softwaretopics/software/story/0,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). members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm

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. www.rubycentral.com/articles/pink

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

Test-Driven Writing   25 Sep 04
[print link all ]
(Source: Stefan Schmiedl)
 >An activity that I /do/ still have trouble with, however, is writing.
 > When faced with having to compse anything more substantial than an
 > email response, I feel the fear start to creep in and I get myself all
 > tied in knots.  Even after I start to put some words down, I often
 > find myself getting stuck because the thing isn't flowing and the task
 > of finishing seems overwhelming.

Yup, writers block definitively, as John Roth diagnosed already. But if you’re able to describe it in such flowering detail as above, there’s no need to have it.

 > So on my way home last night (after another frustrating couple of
 > hours trying to get some thoughts on paper), I was thinking about how
 > I could make my prose writing come as easily as my code writing.  I
 > started wondering if I couldn't somehow employ a TDD-like cycle in my
 > writing process.

I am often writing articles with my business partner, who’s<br>especially good at collecting lots of nice stuff on the web. The first thing I have do with the "drafts" I get from him, is to find the<br>structure fitting best to the available data. This is currently donein a Mindmap using freemind (freely available at sf.net, IIRC). For some<br>time I also tried vimoutliner (www.vimoutliner.org) for this, but found that for this process, the two-dimensional display of a mindmap is better suited to my brain.

When the outline is finished, I start to grow the flesh on the bones. That’s relatively easy, as I confine my work strictly to the current paragraph.>

The next step is easy, if I have the time: I let the stuff settle for a few days, then go over it once more and clean up the unbelievable mess I created then. If I don’t have the time, I need to play about two hours nethack, which erases my brain just as well…

So the steps are:

 - data collection
  - gradually by experience
  - by force (coauthor delivery)
 - data organization
   - mindmap
   - outline
 - draft
   - follow the map
   - work local
 - refactor or polish
   - grammar, spelling, rhetoric
   - present line of thought more clearly

I think that there’s a difference between code and prose showing here. You expect your code to give certain results for a given input, and you are free to not care about the implementation at all. With prose, implementation is almost everything. So the cost of providing a "working release" is higher with prose than with code. At least for me.

 >find myself getting stuck because the thing isn't flowing and the task
 >of finishing seems overwhelming.

Writing is like every other kind of art. It is never finished. Feeling better now?

Writing is like dealing with animals. Don’t be afraid of it, and it won’t hurt you.

Your fellow author in pain, S.

[XP] RSS for Xprogramming blog   25 Sep 04
[print link all ]
link

Ender's Game and Software Development   25 Sep 04
[print link all ]
Very interesting entry by /\ndy Hunt. Ender is in reference to a novel by Orson Scott Card called ‘Ender’s Game’. Its part of a series of three books, all of which are well worth reading. www.toolshed.com/blog

Hang the code, and hang the rules   25 Sep 04
[print link all ]
Douglas Seelinger posted this in the XP-list:
 A quote from "Pirates of the Caribbean: The Curse of the Black Pearl":
 --You're pirates. Hang the code, and hang the rules. They're more like
 guidelines anyway.

Don't do code reviews. Do pair programming   25 Sep 04
[print link all ]

(Source: Ron Jeffries in the XP-mailinglist) Well, Don't do Code Reviews, do Pair Programming. Frankly, code reviews are /so/ much worse than pair programming that a dose of them would make me fly to pair. Let's see if we can replicate my experience.

Here's one path through a network of a million decision points:

To do code reviews, everyone has to read the code beforehand, unless you're doing a walkthrough, see below. I'd ask everyone to come together physically to the review. Then I'd ask them to report truthfully how much time they spent reviewing the code. Early on, I would report truthfully that I had spent zero or very little time, in hopes of getting others to admit the truth. When they admit the truth, I'd dismiss the meeting and reschedule it.

Then, after a while, the only alternative is a walkthrough, since no one is preparing effectively for the review. So we do walkthroughs for a while. They are intensely boring, and few people stay involved. Note in your mind the people who are present but not involved. At the end of the session, say, holding your hand up, "Who else had a real problem staying engaged with this walkthrough?" If there's honesty in the room, hands will go up. Prompting may be necessary. Then: "Any ideas?"

Surely someone will think of "doing this in smaller groups or one on one". Try it. Ask the team whether "we should empower the one-on-one folks to change the code, and under what circumstances." Don't mention that this is pair programming.

Try an experiment. You're "interested in collaborative programming". Interested parties should come to the room to help. On the screen, start writing a program. Ask for help with it, get the room to pair with you. Get stuck (no need to fake this if you are me). Someone will start telling you what to do. Don't get it (no need to fake this either). Get them to come up and do it ... grabbing the chair that is accidentally beside you, while you move over.

Note that reviews often find things. Observe how many of them are resisted by the original programmer, or are "too much trouble to fix now". Build a few BVCs relating to time spent prepping, in the meetings, number of useful suggestions (by person if you can do it without problems), number of changes made in response to suggestions, ...

Code reviews are intensely painful, in my experience, and we were trained by Freedman himself. There will be no need to set them up to be perceived that way, though it will take honesty among the group to express it. After doing enough code reviews, which take way more than half the groups' time by the way, a team who has heard of pair programming should be begging to pair. About all you have to do is make sure that no one treats the review session as nap time, and that you are /early/ in recognizing the people who think it's a waste of time. Because they're right.

[XP] Alistair interview on IT Conversations   25 Sep 04
[print link all ]
I was just sent the link for an online interview about agile development. The interview was done last month, it got posted yesterday. You don’t have to register to listen

link

SCRUM vs XP   25 Sep 04
[print link all ]

(Source: XP-mailinglist; thoughtful post by Ken Schwaber) Scrum is purely a project/product management process that can be applied to software projects, hardware projects, marketing projects, and any mix of the above. It does not contain engineering practices or any specific work practices. It is instead a way to maximize the ROI of work.

People who use Scrum in software development environment often adopt one or more of the XP practices to improve the engineering practices of the develpment organization. Scrum calls for an increment of potentially shippable product functionality every iteration. This means a fully cleaned up, refactored, tested, documented ready to go increment. Many organizations are incapable of this. It is easy to bring in XP practices because they are excellent and both Scrum and XP are pretty radically agile.

Project managers using Scrum are called ScrumMasters to differentiate the type of work they do ... they facilitate, manage the process, and optimize the team's productivity. They don't tell the team what to do, nor do they set of pairs of programmers, or parse out user stories. During the iteration, the team is entirely self- organizing ... whether it is doing software development or anything else related to the increment of functionality they are building.

XP seems to focus on team productivity... doing something the right way and as productively as possible. Scrum does this some, but instead focuses more on doing the right thing, getting ROI from building the 20% of the functionality that is necessary to get the value and maybe not building the rest.

We've implemented Scrum without telling the customer, users, or stakeholders. We've done this in one day. We seduce them into iterative, incremental development where they collaborate with us on what to do next. XP seems to require a steeper implementation curve with less acceptance from the users and customers. Scrum can't keep the customers away.

Estimating is a subtle diffrence that points out the XP and Scrum dividing point. XP works hard to estimate very finely defined stories, and to measure and improve these estimates. Scrum keeps the requirements more broad, more in general user terms that are analyzed during the iteration. Estimating isn't as important. The team does what it can, and gets better and better at figuring out how much it can do each iteration as it learns each other, the business domain, and the technology - iteration by iteration. We care more about delivering business value that having defensible estimates, which become meaningless in a collaborative setting.

Scrum also has a formal methodology that lays out how to scale Scrum to any sort of project with any number of people in any number of locations ... all based on the optimized 7 person team. This is an important mangement requirement, but not so important to an engineering discipline like XP.

I feel we are blessed to have such compatible practices and processes to apply to our software engineering projects.

 

powered by RubLog
875 to 884 of 910 articles Syndicate: full/short