Approximity blog home
838 to 847 of 910 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 :-). [groups.yahoo.com/group/extremeprogramming/files/when%20should%20we%20test.pdf]

XP is fractal.   25 Sep 04
[print link all ]
(Source: Ken Boucher posted this to the xp-mailinglist)
 > Surely, you're not calling design documents you built in the middle
 > of a project "up-front" design?

Let’s talk about "project" and "up-front" for a second.

In the old world I came from, a project had a feedback loop. This feedback loop could be considered to have covered design to unit testing, roughly a period of 6 months to a year on many projects. In other words, I would get feedback on my design 6 months after I made it.

Now let’s enter the fractal nature of XP.

My design to unit test feedback loop is the duration of a card in most cases. In some cases it’s as small as design/refactor/new test/new code/refactor/ (which may be a scope of minutes). In some cases it may be as large as an iteration (after all, we didn’t pick the cards in this iteration at random, we had a plan). It may even have been as large as a release plan.

The difference is that I get my feedback quickly and the design I do at any given stage is as small as it needs to be instead of as large as it can be. But I still do design "up-front". I have a plan before I leave the release meeting. I have a plan before I leave the iteration meeting. I have a plan before I even start refactoring before that first unit test. I have to make the same decisions I would have made in the BDUF, the only difference is that I make them as late as possible. In short, I make them just before I do the task that requires that decision to have been made.

XP is fractal. It’s possible to think about an XP project as a large collection of projects, each small enough to be written on 3*5 cards. And I do design for every one of those projects up front.

.. like Xmas   25 Sep 04
[print link all ]
I came across this nice discussion between Phlip and Juergen Ahthing in the XP-ML
 "Without test-first and refactoring, clients think
 they must assemble as many program requirements as
 they can afford to have written. This effort snarls
 all relative business priorities together, making
 Scope Control impossible. It obscures opportunities
 for simplification. Designing and implementing many
 features all at once is very hard, leading to our
 industry's reputation for very large failures. Putting
 tests in front of development's inner cycle permits an
 outer cycle of incremental feature growth. That
 relieves the Customer of the responsibility to predict
 the future and guess which complete set of features
 will maximize productivity."

.. Juergens answer:

 Nice description.
 Sometimes I try to explain that to non technical people
 with the following picture:

 If you have only one chance to get your wishes on a
 list, it is like Christmas for a child. You make sure
 you get every little wish on that list and hope for the best.

 If you are sure that you can get your wishes on the list
 at any time. You will just put the most important ones
 there which come to your mind easily.

Quote of the day   25 Sep 04
[print link all ]
(Source: Kent Beck posted this to the XP-mailinglist)

This from a lean manufacturing consultant:

Find the simple path to what works and follow it, always looking for a simpler path.

Patrick D. Smith

Big Requirements Up Front (BRUF)   25 Sep 04
[print link all ]
I really appreciate Georg Tuparev’s postings to the XP-ML.
 >Because it is important for the customer to have an idea of how much
 >> everything will cost ...

 In 99% of the times customer neither needs nor wants "everything"! One
 of the big dangers of BRUF is that it imposes the wrong feeling that
 "everything" is important. This is a major distraction that inevitably
 leads to scope-creep and eventually project failures. When we have the
 first meeting with a new customer we ask the following 3 questions:
 1. What is your biggest pain?
 2. If we solve this and only this pain, will your life get better?
 3. Are you willing to pay X amount of Euros to us to solve this pain.

 If any of these questions is answered with "no" we just thank for the
 coffee and walk away. If all 3 questions are answered with yes, we move
 to the first planning game...

 Put it in another way: I do believe it is extremely dishonest and
 incorrect behavior to conduct 9 months BRUF only to reach the
 conclusion that the customer does not have enough resources to
 continue. It is dishonest because as I wrote in an earlier posting,
 _all_ good developers I know are able to estimate almost immediately
 the scale of any software project without conducting BRUF.

Story cards are like poker   25 Sep 04
[print link all ]
(Source: Brad Appleton, XP-ML) How cool would it be actually to /use/ poker chips in the Planning Game? Interesting - I interpreted the above statement to be talking about having the planning game include both cards and chips (just like poker). The chips would correspond to story points, and would be attached to a story card with the appropriate number of chips. And when a story was "split" the corresponding chips would be split between the resulting new card(s).
  • The dealer gives the customer all the chips for this iteration
  • Then the customer "shuffles" the cards and lays them down
  • As each one is laid down, development uses a different color of chips and places the number of chips that story costs.
  • If the customer is okay with it, they then take an equivalent number of chips from their "stack" and place it to the "bet" pile.
  • If the customer isn't okay with it, the story can be split (kind of like "double down" in blackjack) and/or cards can be "reshuffled"
  • At any time, the customer may "reshuffle"
  • When the customer is out of chips and is okay with the current "bets" and card order, the planning session is adjourned

Hackers and Painters   25 Sep 04
[print link all ]
(Source: Paul Graham) When I finished grad school in computer science I went to art school to study painting. A lot of people seemed surprised that someone interested in computers would also be interested in painting. They seemed to think that hacking and painting were very different kinds of work— that hacking was cold, precise, and methodical, and that painting was the frenzied expression of some primal urge.

Both of these images are wrong. Hacking and painting have a lot in common. In fact, of all the different types of people I’ve known, hackers and painters are among the most alike. www.paulgraham.com/hp.html

Simple things ..   25 Sep 04
[print link all ]
I was just now doing some research on bus ticket clearing houses and I came across his post in rec.travel.europe from 2001 by Michael Forrest.
 >Reciprocity is not guaranteed on airlines (or toll bridges - it
 >has always amused me that the toll on the Severn Bridge between
 >England and Wales is GBP 4.20 for a car to enter Wales but there
 >is no toll the other way, ie entering England). (Maybe it shows
 >how the two countries value themselves?)

All of the bridges in the San Francisco Bay area only charge toll in one direction. Some genius realized that, on the average, just about as many cars went each way for the obvious reason that most trips across the bridges are round trips. So they doubled the toll and took down the toll booths going one way (except for the Golden Gate Bridge where the toll booths remain, unattended). There has been considerable saving in toll collection costs and the toll booth traffic jams in one direction are gone. Is it possible the Severn Bridge does similarly?

Just Ship, Baby   25 Sep 04
[print link all ]
(Source: Kent Beck) Short two page essay: The focus on shipping is not an excuse for cutting corners, but perfect adherence to the practices is no excuse for not shipping. groups.yahoo.com/group/extremeprogramming/files/just%20ship.pdf

Game Design & Engineering Theory   25 Sep 04
[print link all ]
(Source: Miyamoto’s Tokyo Univ. Lecture Today (July 3), at the Komaba campus of Tokyo University, a lecture was held by Shigeru Miyamoto, director and head of information development at Nintendo Co., Ltd. I’ll write out the main points of the lecture here. I’ve deliberately left some parts out; my apologies for this.

…I arrived at the classroom ten minutes before the lecture began. I was worried that there wouldn’t be any seats left, but I discovered one at the fourth row from the front so I hurried over and sat down. The classroom, which can hold around 200 people, filled up almost instantly. By the time I entered the room, Mr. Miyamoto was already sitting in a chair next to the blackboard.

Since Miyamoto was apparently too busy to make any special preparations for the event, it was decided to move from a traditional lecture format to a more informal discussion. To start off things, the instructor in charge discussed CERO [the Japanese game rating system], age restrictions, GTA, Kakuto Chojin, and other topics related to game regulation.

And then Miyamoto stepped up to the mike. Applause…

www.video-fenky.com/features/miyamoto.html

 

powered by RubLog
838 to 847 of 910 articles Syndicate: full/short