1) Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.

2) Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed.

3) Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.

4) Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

www.jwz.org/doc/worse-is-better.html

How can software development productivity be increased? Through the same approaches used in operations: a focus on customer value, a short, effective supply chain, healthy discipline, and innovation. Mary will discuss techniques that businesses have used for decades to jump-start an increase productivity, and show how they can be used to increase software development productivity. pdf

 "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.

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

 Inside my head, I sometimes refer to Del.icio.us as the Google In Reverse.
 Google has amassed a solid mound of ranked and twined web sites. The
 standings shift about with caution, the behemoths are tough to dethrone.
 And if I ask for Ruby, the answers in place may hold through the end of
 the year.
 ...
 Del.icio.us is perfect! The activity bred by competitive linking would
 be enhanced by the sharing of richer media.
 ...
 Better client software is needed to make this happen.

Samizdat homepage

Slides Dmitry Borodaenko presented about Samizdat ath the Euruko 2003

• 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

 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.

• 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

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

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

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.