How do you design/spec your applications?

This is going to seem ridiculous to most of you but bear in mind that I am a "one man band" and all of the programs I make are free... basically whenever I have made programs in the past I have not done much (if any) planning or specification. I have just sat there and essentially made it up as I go along, which has often led to very messy code later down the line. The justification for this in my mind was that because most of my programs are just small little 'utilities' that do not have a very long lifetime and so there was no point spending more time planning than actually making the things - for example one of them just downloads specific updates from windows update so that people can still get this important update without having automatic updates enabled on their servers (its an update for exchange server spam filters which MS release every 2 weeks). So yeah, the program itself would only be open for less than a minute so it seemed pointless planning it all out when it only took a couple of hours to make. Another example is one that adds or removes users to/from Active Directory groups. So none of them have really required a lot of planning... although they certainly would have benefited from SOME planning.

However, now I am creating a job logging system for IT people (mainly because the one I use everyday at work just annoys me and makes me think for gods sake I'm sure I could write something better than this if I had enough time!) and this is going to be by far the biggest program I have ever written. Well, it will consist of more than one program... there will be a WPF client desktop program, an ASP.NET front end (sometime in the future), a WCF service hosted in a windows service, and an SQL database to store all the data.

So, I suppose I should get to the point.
Although I already made a start on the WPF user interface quite some time ago, I have now stopped work on this and decided that I need to spend some serious time planning and designing this solution.
I've made a few flow diagrams for some core processes, such as logging a new job, and have made a list of what will be in each section of the program. For example, in the Job Logging section there will be the ability to: create a new job, update a job, close a job, filter jobs based on who they are assigned to etc etc. This is all fairly high level stuff though and it only takes up a couple of pages in a Word document... so im just wondering what/how you guys plan and design before you even begin writing any code? Any tips on where I should start or even what sort of things I should document and how much detail I should go into?

Thanks
Chris

PS if anyone has a lot of experience with N-Tier or SOA applications, maybe you could help me with the general architecture, have a look here: http://www.vbforums.com/showthread.php?t=570048 :)

I find the best bet is to first come up with a few paragraphs that explain the application as if you where writing it for someone else. This will help collect your thoughts together. It is hard to do at first but you will get the hang of it.

Next I mock up some very VERY basic screens in a test project so I can work out what needs to go where. I tend to "print" everything to onenote 07 as I can organize better using it.

by the time I have some sample screens I tend to have a better picture of how the application will function and will start to create conceptual objects. These are basically little squares with responsibility and dependency information in them.

by now I have a list of objects and what they do so I do out a table in the order each needs to be completed or if two need to be completed in tandem. This gives me a structure to work off.

I use the above structure to create class files in a solution. Each file is then populated with pseudo code. This section is very important as things like object incompatibility or merging tends to take place.

I refine each object further in pseudo code. The start as a comment paragraph, then into step by step instructions. At this point coding will be trivial in a sense. Sure there will be code that you need to implement that you have never used before but at least you know what this code should achieve. I never remove to steps though as I tend to use them as comments.

Obviously I have glossed over this a bit so do understand that there is a lot of refinement involved but it tends to be much easier to change a line of text then a line of code and by the time your pseudo code actually looks like code 90% of your refinement will have routed out silly errors and "where do I go next" issues.

Thanks Dean, that gives me something to go on at least (although I've never looked at pseudo code before!)

It is not as hard as some people claim it to be. You basicly write your statments in english rather than code. This allows you to get the flow of the program down and theorecticlly you could have the whole application "complete" in pseudo code before even had a line of actual code written!

I start with rough diagrams, each of which represent what each part of the application will do - this is so that the organization is right. Functional aspects and all that.

Then it's database diagrams, because at this point I know what I want.

Then class diagrams.

Then start working with these classes and the database; as you go along, you'll need to make several changes to the classes/data, but they won't be drastic and the changes or even the code won't be messy.

So it's something similar to what DeanMc said, only more awesome.

Meh, you mean not nearly as awesome since I get to use the word pseudo!

thanks for the input mendhak :)