Here's my take on things, (follow the link in neophyte's post for better reasoning and more cogent analysis):

• Software changes all the time
• Software requirements change all the time
• Doing a complete design up front is a big investment that pays less and less the more you change
• You can't predict what will happen more than a week or two in advance
• When you actually start coding, you'll find better ideas
• No one wants to update the design documentation while you're coding
• A large design at the start can lead you to the trap of making things too flexible, adding functionality you don't need just yet
• If the project is always in a functional state, you can deliver it to the customer nearly anytime
• If the customer chooses the features that provide the most business value and you work on them, you can maximize your return on investment
• Write the simplest code that could possibly work. It's easier to debug and to understand that way.

I'm not saying that design isn't important. I'm just saying that spending a couple of weeks at the start of a project doing nothing but design is not (in my experience) going to pay off in six months, when the specifications have changed, the original design didn't work, and no one wants to update a few dozen CASE diagrams or pages of UML.

Certain industries where accuracy and reliability need to be mathematically proven may have different requirements.

XP practitioners try to 'code by intent', where they write a test case for the feature they're about to add, let the test fail, then write code to make the test pass. That's design in the small.

For design in the large, they write stories about the features the software needs. The customer arranges them by their value in the shipped product, and the team tackles them in that order. Design is done as-you-go, with a little up front investment in the basic architecture (the simplest that could possibly work), breaking a story down into programmer-afternoon-sized-tasks, and continually refactoring.

That may or may not work for you, and it may or may not work for my latest project. We'll see.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.