README.md

     A lot of people never finish most of the projects they start. "Finishing a project is the hardest thing" -Secrets of the Sages. The problem can occur at any point and for any reason. For example, my biggest problem is learning something new and jumping right into starting a project for an idea that popped in my head. Well, let me tell you, serious psychological problems as well as bad habits can occur. Not finishing a project is one of my worst bad habits and in return, it has weighed heavy on my mind. Depending on the person, depression can occur. You might take these statements lightly, but you can ask any of my coworkers and my wife.

     Most projects are just something to entertain me at the time. If I had taken the time to properly plan out my ideas into working projects before just hacking code, I would have

1. Figured I'd be wasting my time and would not even bother to start as I already knew I would lose interest, or something else would keep me from finishing
2. I would finish the plan and I would have a nice road map to complete the project.

     This is the point of this article right now. Learning to manage projects and keep your peace of mind. Let's take a look at the overall process of planning your ideas into projects

• Idea stage
• Thinking stage
• Preplanning stage
• Planning stage

     Now these stages are just a quick overview of the process. Let's get into some details of each stage.

Your Idea
     OK, so now you have an idea. Ideas are really fun and great. They get you all excited because you have something new to try out and learn from. Something to show your friends. I know this feeling all to well. It's a rare day I don't read about a new language or about how to do something new in a language I already know, or get an idea for a new program that I could market, etc. Does this sound familiar? Well, today, I started learning about the benefit's of XML. And since I've been working with Perl the last few days, I had another idea pop into my head. I want to build a piece of software that I can market using Perl and XML. Now, as always, I have the idea and I say to myself, wow! This will be so easy! So I just jump right into it. After a little while, I see all these things that get in my way and it puts a stop on the project. Had I taken the time to plan it out, I would have seen these things. Luckily, this time I am taking it slow.

     Getting yourself organized is the first step. Another serious problem that plagues me, is that I have ideas everyday and they all generate the same response. Since not a good idea to work on 50 projects all at once, if you cant even finish one, go buy yourself a journal, notebook, palm pilot, or if your a poor starving coder, then use notepad! Anything that works for you is fine. Make an idea chart. Each time you get an idea, write it down. Not only will this allow you to focus on your current project, but it will keep your from forgetting about them later, and most important, it will help you weed out projects that you would normally not finish due to it being one of those, "Keep me entertained at the time" projects. Very important.

Thinking stage
     This stage is a must. The reason why is because in this stage, you will be defining what your project is. You must define a clear definition of your goal. What will your project be at the finish line? What is the purpose of your project. Before brain storming about all of the ideas you want in your project, you must clearly define this information.

     Once you have a clear definition, you can start your brain storm session. Be sure to use your notebook (or start a new text file) to write all of these ideas down so you do not forget them when it comes time for planning. When you are logging these "bells and whistles" that you want to feature, include details and any specific information you have in your mind. You might think, "I will remember what I meant when I see what I wrote down", but I cant count how many times I have said that to myself only to come back anywhere from a week to 6 months later only to find that I have scribbles that are very cryptic to me. Someone else may as well have written them.

     During this thinking stage, you will want to get opinions and comments from other people and write them all down. Remember, this is just a thinking stage. Getting a lot of information now can help more than not having enough later on.

Preplanning
     If you are still interested in your project at this point, then finishing this stage is our next goal. Preplanning goes like this, you take all of the notes and scribbles and comments and suggestions and you sort them out. This is where you make sense of all the data you have acquired. You must weed out bad ideas and keep the good ones. Use the suggestions and comments to build, modify and improve your ideas and form them into solid, legitimate additions to your project. A lot of people would include features that are useless in the end, but look good now. Time wasters are what they really are. Now with the ideas you have left from that mess, you must determine how each idea will fit into your project. If it don't fit, put it a side. You can always add it in the next version.

     OK, now we are at a critical point in our process. Here, you need to decide if you should repeat the "Thinking stage", or if you should continue on to planning. Now before we get into planning, you will need to understand some guidelines. Any new ideas that arise will complicate and potentially ruin your plan. So, if at any point from here on, you get new ideas, write them down like you did before. But this time, you will have a different agenda for them. These ideas will go into your next version, or will be added only after you have finished your original plan. If you think that they are too good to pass up, go back to the thinking stage.

Planning
     Our last stage is by far the most important. During this time, we will design and layout our project road map. From this map, we will start and finish our project. Now, this stage in it's self has many sub stages that must be followed.

• Putting the puzzle together with a design document
  -Defining your resources
  -Defining sections / goals
  
• Starting at the start

     Now we have an overview of our planning stage. Let's get started!

Putting the puzzle together
     After our preplanning stage, you should have everything that will be in your project. You will need a new piece of paper (of a new text file) because you are going to create a design document. If you have ever been involved in a big project, or have read about them, you will know that the design documents are the "bible" and will be the highlighted path to your destination.

Creating your design document
     A design document is the key to your project. It holds the outlines of everything that goes into your project. From the user interface to the push of the 'OK' button. Lets take a look at what should be in your design document

• The purpose of your project
• A clear definition of what the end result will be
• Defining the 'tools' to be used
• Drawings/Sketches/Renderings (User interface, menu's, splash screen's, models, etc.)
• Feature placement and function
• Defining people who are involved and their duties/responsibilities
• A breakdown distributed resources

     We have defined the purpose and the end result in the preplanning stage and should not be difficult to add to the design document. Defining the 'tools' you are going to be using is another easy one. Let's take a game as an example. If you were to be building a game, you would surely want to define what API you were going to use (OpenGL, DirectX, Software blitting, etc.). If using 3D models, you will need to define the file type and software used to create these models, otherwise, define the sprite file type and format's. Sound, input, distribution, and many other things will need to be defined. Since it's a compiled game, you will want everyone working with the same compiler. As we all know, Borland and MS don't mix very well.

     Drawing and sketches (if applicable) will help to give a visual aid to you and everyone in your project. Even if you have a clear vision in your head, it will be distorted by the end and it can cause serious side effects. Put it in ink and leave it alone. If you feel you have to tweak on it, leave it be until you are done. I cant stress this enough, wait until you finish until you make changes. If you feel that the changes are necessary now and can not wait until after your project is finished, then you will need to go back to the thinking stage. This is OK since you have not started on any work at this point. You might lose a little time, but it will be worth it in the end.

     Feature placement and function goes along with the drawings/sketches if applicable, otherwise, describe how they will fit in to your project, what their purpose is and how they will function.

     If you have other people involved in your project, then you will surely want to spend time on your resource section. It will be an outline for everyone and what their jobs are. To maximize your time, you will want everyone to have a job all of the time. To go even further, you will want to add 'odd jobs' that anyone can work on if they complete an objective and have some free time, even if it's sweeping the floor (considering everyone is all together and not spread out over the Internet). Define a project leader. Who ever that individual is, should be responsible, since it will be their failure should the project fail. If you are not willing to take responsability for failure, dont be the leader!

     Defining your resources, if any at all, includes time, money, workers and materials (depending on the job). Step back from your project and look over your objectives and everything involved so far. If you are paying people to work on the project, then you have to define a budget, and with a budget comes a time frame. Let's define a scenario

• 5 workers @ \$10.00/hr each
• \$50,000
• No time frame
• Software application for database interaction

     OK, so this is our 'box' that we must work in. A good thing is that there is no time frame, so you can mess around all you like. Your budget is \$50,000 and there is nothing to buy since everyone has their own workstation, and all the tools they will need. But, you are employing people to code software and they work 8 hours a day, 5 days a week. All 5 employee's are being paid equally @ \$10.00 /hr. This means that every month, \$8000 comes out of the budget.

((10*40)*4)*5 = \$8000
((Hourly rate * Hours per week) * weeks per month) * Number of workers = Total monthly cost in worker pay only

     All of the sudden, there is a time limit on the project! Since the budget is \$50,000, the time limit is approximately 6 months. You better get started! Define a time limit for each section of your project and stick to it. If you have to work for free on the weekends, then you had better do it.

     By now, you should have a pretty good design document. I haven't covered everything, but creating docs over and over again, you will learn more and more what you must include for everything to run smoothly. We talked about setting time limits for each section. Let's take a look at defining sections and goals.

Defining sections and goals
Since you cant do everything at once, you must do small sections over time. This is a tough job, but it is critical. You have to take your project as a whole and break it into little, manageable pieces. Let's go back to our software project we defined in the example above. If only one person were to be working on this project, the sections might be broken down as such

1. Create user interface     1/2 month
   - Create graphics
   - Create the menu's
   - Layout objects (button's, etc.)
2. Code the menu items     1/2 month
3. Code objects (button's, etc.)     1 month
4. Code the database wrapper DLL     2 months
   - Connect, Close, Add, Search, Delete, Edit
5. Code the features     1 month
6. Test / debug / fix     1 month

     This is a small simple break down but it should get the point across. By following your break down, and finishing each piece individually, you will have your project finished in no time. It will also help to keep your attitude on the positive side because you can look back and see what progress you have made. Attacking the project as a whole with no direction can hurt the moral when you look back after 6 months of hard labor and you have nothing finished to look at.

Starting at the start
     Isn't it so fun to get right in and start hacking away at your project? Yes it is. I love just jumping in and start writing code with no direction at all. But, after reading this article, I'm sure you will want to start where you should, and that's at the beginning. Planning is key to your success. Think about war. If you had an army, would you have a better chance of taking over a country if you had a plan, or if you just sent all of your troops in blazing at random? That's my point. Designing the layout of your database isn't fun, it's boring and mundane, but it must be done before you start writing code.

     I hope this article has helped at least one of you. It has helped me in many ways. Look for more articles from me @ Programmers-Unlimited.com