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.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.