Re:Sometimes you gotta take a look around. (Score 3, Insightful)

1) Extreme programming doesn't mean skipping design, it means building only what you need. You're still building that little bit with the same attention to all facets of software engineering.

The point being that when you don't know what you'll eventually have to build, no amount of intelligence, forethought, or design will solve that problem. You build what you know you need, and flow along with changing requirements.

2) Who's to say that the better overall choice is to correct the so-called "negative traits". There is some cost associated with doing so. If they are important enough, they will get fixed. Maybe (as is often the case) getting something that mostly works makes the users happier than something "properly design[ed] from the start" yet six months later.

(Not to say that design slows down a project; attention to design should and will speed up work. But too much Capital-D Design up front -- before the questions are really explored, and before you have a working version to pound on and gain understanding from -- will end up a losing proposition in the end.)

The blessing and curse of software development is that everything you are doing is necessarily new in some way. If someone has done it before, why would you be writing it again? That combined with the push to solve the difficult problems in software rather than hardware (because software is *easy* to change!?) means each project is an exploration.

And to the extent that the exploration is into more and more unknown territory, you need the steps of iterative and "agile" processes to get yourself a good feedback loop into your problem domain.

Otherwise you end up over time and over budget (if it even works at all), because you had a great design for the wrong problem.