Projects that were found to meet all of the traditional criteria for success—time, budget and specifications—may still be failures in the end because they fail to appeal to the intended users or because they ultimately fail to add much value to the business.

... Similarly, projects considered failures according to traditional IT metrics may wind up being successes because despite cost, time or specification problems, the system is loved by its target audience or provides unexpected value. For example, at a financial services company, a new system... was six months late and cost more than twice the original estimate (final cost was $5.7 million). But the project ultimately created a more adaptive organization (after 13 months) and was judged to be a great success—the company had a $33 million reduction in write-off accounts, and the reduced time-to-value and increased capacity resulted in a 50 percent increase in the number of concurrent collection strategy tests in production.

In this sense I see a startling parallel between DHH [David Heinemeier Hansson, creator of Ruby on Rails] and Kent Beck. For either of them, if you present them with a constrained world, they’ll look at constraints we take for granted, consider them to be unessential, and create a world without them. I don’t have that quality, I tend to try to work within the constraints gradually pushing at them, while they just stick some intellectual dynamite under them and move on. That’s why they can create things like Extreme Programming and Rails which really give the industry a jolt.

The GMS team delivered this product after three years of development [60,638 lines of code], having encountered a total of 51 defects during that time. The open bug list never had more than two items at a time. Productivity was measured at almost three times the level for comparable embedded software teams. The first field test units were delivered after approximately six months into development. After that point, the software team supported the other engineering disciplines while continuing to do software enhancements.

Our team delivers a predictable amount of work every iteration. Because we had a velocity of 14 story points last week, we’ll deliver 14 story points this week, and next week, and the next. By combining our velocity with our release plan, we can commit to a specific release schedule!

Every project faces a set of common risks: turnover, new requirements, work disruption, and so forth. These risks act as a multiplier on your estimates, doubling or tripling the amount of time it takes to finish your work.

How much of a multiplier do these risks entail? It depends on your organization. In a perfect world, your organization would have a database of the type shown in . It would show the chance of completing before various risk multipliers.

Figure : An example of historical project data

Because most organizations don’t have this information available, I’ve provided some generic risk multipliers instead. (See .) These multipliers show your chances of meeting various schedules. For example, in a “Risky” approach, you have a 10 percent chance of finishing according to your estimated schedule. Doubling your estimates gives you a 50 percent chance of on-time completion, and to be virtually certain of meeting your schedule, you have to quadruple your estimates.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. —Antoine de Saint-Exupéry, author of The Little Prince

Any intelligent fool can make things bigger, more complex and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction. —Albert Einstein

Venners: The GoF book [Design Patterns] says, “The key to maximizing reuse lies in anticipating new requirements and changes to existing requirements, and in designing your systems so they can evolve accordingly. To design a system so that it’s robust to such changes, you must consider how the system might need to change over its lifetime. A design that doesn’t take change into account risks major redesign in the future.” That seems contradictory to the XP philosophy.

  1000 NS% = (80 - LEN(T$)) / 2

  1010 S$ = ""

  1020 IF NS% = 0 GOTO 1060

  1030 S$ = S$ + " "

  1040 NS% = NS% - 1

  1050 GOTO 1020

  1060 PRINT S$ + T$

  1070 RETURN

  public void PrintCenteredString(string text) {

      int center = (LINE_LENGTH - text.Length) / 2;

      string spaces = "";



      for (int i = 0; i < center; i++) {

          spaces += " ";

      }



      Print(spaces + text);

  }

A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable runtime performance.