This will be a very interesting thread for me too.

Generally, and probably not strictly in this order, I tend to work like this:

Gather user or desired requirements. This is usually more complex than it starts out sounding. It tends to run from UI elements, desired functionality devoid of UI requests, desired output and displays, application management functionality, user management, "what happens after that?", "what should we see on *this* screen", etc. Also included are data requirements, etc., so thinking regarding data storage, existing db mods, and the like can be worked on. My experience is that this step is repeated many, many times throughout... :)

Gather resources based on what I know so far. That may mean investigating existing app(s), db and structure, CPAN exploration, lots of books, etc. Generally I do this pre-design to help me start thinking it through. I'll look for prior solutions, etc.

White board, butcher paper, markers, etc. Flow charts, liberal attempts at pseudo code (which is where I get ideas about modularizing code, etc.) Often the pseudo code then gets summarized into an outline or diagram form as an overview. Try to explicity define any/all subs, objects, modules; in/out for each, etc.

Write tests for discrete units. Often, this is where I tend to shortcut and it's a weakness.

Code a first layer of core functionality, test. Add more functionality. Generally, I try to 'get the basic issues functioning' first, then layer onto it. At various stages I'll return to the first step to double check if we're on the right track - but the warning here is that there can be way too many changes if this is done too often. Big surprises in design or major feature creep are really undesirable at this stage... lol

Test, etc... prior to alpha/beta.

It's a very dynamic process for me and not as rigid as it may sound, and probably not near as formal as more professional folks may approach it. It's always seemed important to me to get the core functionality working as quickly as possible for my own morale, and for the morale of any team members and/or clients...

I've used a few design tools, but my tendency seems to be big white boards, big pieces of paper and diagrams as thought tools first. Should the project or client seem to require formal paper stages, or if the project is complex enough, I/we certainly do them.

---

---

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.