Peter Marklund's Home

I am reading "Software Project Survival Guide" by Steve McConnell which I find very useful. Since McConnell is talking about upstream and downstream activities (waterfall approach?) and emphasizing that changes are vastly costlier when they are made late on in the project, I was curious as to how compatible his approach is with Extreme Programming. The following links provided some insight:

• Notes from Steve McConnell 2004 Keynote speech
• The Case for XP

I found this section from McConnell's speech particularly illuminating:

Design Advice -- What has changed in 10 years?

    * In 1990s, design pundits wanted to dot every i and cross every t before writing any code
    * In 2000s, say BDUF (big design up front)? YAGNI (you aren't gonna need it)
    * There are lots of valid points on the no design--all design continuum

Extremes are usually not productive

    * All design up front vs. no
    * Entirely planned vs. improvised
    * Pure iterative vs. straight sequential
    * All structure vs. all creative
    * Document everything vs. nothing

Maybe it is in the overlap of the different software project management approaches that we, using our common sense and experience, can find the method that works best for the particulars of our own software projects.

In the book "Extreme Programming Perspectives", Pascal van Cauwenberghe offers this acronym for finding the balance between up-front work and refactoring:

"Instead of using the disparaging term "big design up front" (BDUF) we should be investigating how best to determine what is "just enough design for increments" (JEDI)."