| Samizdat - 0.5.2 is out
|
|
25 Sep 04 |
|
[print
link
all
] |
|
Samizdat is a generic RDF-based engine for building collaboration and open
publishing Web sites. It will let everyone publish, view, comment, edit,
and aggregate text and multimedia resources, vote on ratings and
classifications, filter resources by flexible sets of criteria, and
cooperate and coordinate on all kinds of activities. It intends to promote
values of freedom, openness, equality, and cooperation.
Samizdat homepage
Slides Dmitry Borodaenko presented about Samizdat ath the Euruko 2003
|
| 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
|
| Knowledge Management from personal content management tools
|
|
25 Sep 04 |
|
[print
link
all
] |
I shamelessly copy this blog-entry from here
Below is a quote from Dave Pollard, the former Chief Knowledge Officer from
Ernst & Young. It is a great paragraph because is is truly representive of
why enterprise knowledge managment solutions failed. He is talking about the
fact that knowledge managment systems have to be personal content management systems first.
Quote:
I believe personal content management tools are the place to start, because
since the earliest days of business, the principal way of sharing information
has been peer-to-peer, the most valued 'repositories' of business information
have been personal filing cabinets, and the principal schema for organizing
work has been the personal desktop. It makes sense, therefore, that tools
that facilitate and reflect these well-established 'knowledge processes',
information sources and networks should be much more successful than the complex,
centralized, hierarchical knowledge management tools and repositories that have
been foisted on users for the past decade.
End Quote:
It is a great quote because how is it possible that anyone could believe that
a centralied hierarchical tool could work when it was in no way related to how
people did and have done knowledge work since the beginning.
|
| Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck
|
|
25 Sep 04 |
|
[print
link
all
] |
Very interesting book. Highly recommended. This books brings the lean
production principle to software development. Seven lean principles:
- Eliminate waste: Spend time only on what adds real customer value
- Amplify learning: When you have tough problems, increase feedback
- Decide as late as possible: Keep your options open as long as practical,
but no longer
- Deliver as fast as possible: Deliver value to customers as soon as they ask
for it
- Empower the team: Let the people who add value use their full potential.
- Build integrity in: Don’t try to tack on integrity after the fact -
build it in
- See the whole: Beware of the temptation to optimize parts at the expense of
the whole
Link
|
| How Org Charts Lie
|
|
25 Sep 04 |
|
[print
link
all
] |
|
(source: Harvard Business School) In an excerpt from Harvard Business
School Press Hidden Power of Social Networks, learn how "social
network analysis" reveals problems your org chart ignores. link
|
| 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.
|
| 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
|
| 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.
|
| Advantages of Extreme Programming
|
|
25 Sep 04 |
|
[print
link
all
] |
|
(Source: Kevin Smith post to extremeprogramming@yahoogroups.com) After a
couple years of pitching XP, it became very clear to me that XP has
different key advantages for different audiences. You’ll have to
decide whether to pitch to a single audience, or try to cover several.
For developers, XP allows you to focus on coding and avoid needless
paperwork and meetings. It provides a more social atmosphere, more
opportunities to learn new skills, and a chance to go home at a decent hour
each night. It gives you very frequent feelings of achievement, and
generally allows you to produce code that you feel good about.
For the Customer, XP creates working software faster, and that software
tends to have very few defects. It allows you to change your mind whenever
you need to, with minimal cost and almost no complaining from the
developers. It produces reliable estimates so you can coordinate your
schedule easier.
For management, XP delivers working software for less money, and the
software is more likely to do what the end users actually want. It cuts
risk in a couple ways: 1) It allows you to "pull the plug" on
development at almost any time, and still have highly valuable code, and
probably even a valuable working (if incomplete) application. 2) It reduces
your dependence on individual superstars, and at the same time can improve
employee satisfaction and retention.
The biggest disadvantage: It’s hard. It’s difficult to get many
developers to accept the practices, and it takes a lot of discipline to
keep doing them all. Customers may not like the idea of having to be so
involved. Management may expect fixed-cost, fixed-scope estimates, which XP
teams often refuse to create (because they are usually incorrect with any
methodology).
Also, certain people may feel their jobs are being threatened, particularly
architects, testers, and project managers. "Cowboy" coding
"superstars" may dislike the reduction in fame, attention, and
adreneline from "saving" the project at the last minute.
|
| Software for your head by Jim and Michelle McCarthy
|
|
25 Sep 04 |
|
[print
link
all
] |
What Ron Jeffries says: if you read this book, really study and consider
it, you will think thoughts you haven’t thought before, and you will
likely learn something about yourself, your colleagues, and your projects.
I read a lot of books and recommend a lot of books. This one is special. Do
yourself a favor: buy it, read it, and give it deep consideration.
|
| Lean Manufacturing and Software
|
|
25 Sep 04 |
|
[print
link
all
] |
|
(Source: Bill Wake) Is writing software more like manufacturing cookies or
more like designing cookie cutters? It’s easy to wish that we could
develop software like a factory stamps out cookies, but software has a
design or creation element that is missing in that analogy.
But there are similarities: software is developed in stages, it is created
in a process amenable to change, and it’s developed in a team. Lean
manufacturing is a different approach than a traditional assembly line, and
offers some lessons for software development. xp123.com/xplor/xp0312/index.shtml
|
| 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
|
| Software Bug Causes Soyuz To Land Way Off
|
|
25 Sep 04 |
|
[print
link
all
] |
|
A mysterious software fault in the new guidance computer of the Soyuz TMA-1
spacecraft was the cause of the high-anxiety off-course landing over the
weekend, according to NASA sources.’ Which is why I will never trust
the Strategic Defence Initiative - the star wars project. It only takes one
line of mistyped code in what will always be a beta release. www.msnbc.com/news/909677.asp
|
| Extreme Leadership
|
|
25 Sep 04 |
|
[print
link
all
] |
|
An interesting read. Patterns of extreme Leadership by Kent Beck. pdf
|
| 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: www.nwlean.net/no_harm.zip 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."
|
| 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
|
| 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.
|
| Modeling on White boards
|
|
25 Sep 04 |
|
[print
link
all
] |
|
(Source: Scott Ambler) I just posted "Software Modeling on
Whiteboards" at link.
It describes how whiteboards can be an effective modeling tool.
Basically it’s an ad for Whiteboard Photo. ;-)
|
| fit
|
|
25 Sep 04 |
|
[print
link
all
] |
|
Ward Cunningham has released an acceptance testing tool called fit fit is about tests that people can read.
The Cook’s Tour
offers an excellent howto to get yourself and your customers into the
test-writing mode.
An intro
article by Bill Wake.
|
| 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
|
|
|