Eryk

"Planning ahead saves tons of time later on"
-- Everybody who plans, or acts like they plan

I've heard that saying so often. Yet, I've never really seen anything on what to plan, or how you should plan, what steps you should take, et cetera. So I'm wondering for all those who do plan, what do you plan, how do you go about doing it, do you do it in a certain order, and I'm basically repeating my last statement as a question?

Nebula

I normally take a program that already exists and try to think of ways to make that program better, faster, and more reliable. I usually dont take that same program but make a clone of it. If I'm starting from scratch then I usually think of something I need or want and do some research on it and see how it works etc. Then do my best the first time, make the second version and see what I can improve, it really just goes form there. This is just my opinion and method. Good Luck!

__________________
When will Jesus bring the porkchops?

ReggaetonKing

To be honest,I just start writing the basics on the program and add the components I need as I go along. My VB teacher said its very bad programming practice but I have a 99 in that class, so....lol. I am honestly going to start now planning! I will write down what is be needed for the program, (what research, formula, etc.), but to tell you the truth I dont write pseudo-code. I think its kinda worthless but in a way it's not, idk I dont see myself writing in.

But here is some advice:
1) Write your goal for this program(what will it accomplish?)
2) Do I need a GUI or texted based?
3) What information will I need to research?
4) How can I improve it?
5) Is there an easy way to write the code for it?
6) Where can I reference from?

thats some good practice on planning!

__________________
I would love to change the world, but they won't give me the source code!

crazykid48x

I dont plan much either. I find that after alot of extensive planning I rather take a nap than start coding. Then once I wake back up and read over my plans, they never seem to make much sense.

I do, however always have a list of features for my program, listing everything my program should be able to do, before I start coding.

__________________
I had my portable CD player, and took it in the bathroom with me while I went to pee. And the second I whipped my penis out, the theme song to 'Rocky' started playing. I've never felt more manly than in that moment.

Arevos

There is something you need to do before the planning stage that, in my opinion, is just as important. With open source tools and languages a penny a dozen, a mere Google search and download away, for most projects some time spent doing research will not go amiss. It's quite likely that someone will have had a similar problem to the one you face, and it's also pretty likely there will be some tools, libraries or languages that will make the job easier. People reinvent the wheel far too often in software.

When you do get to the planning stage, it doesn't have to consist of hundreds of UML diagrams and written documents. It can just be you thinking for a few hours, perhaps with a pen and paper, or writing on the back of a napkin. Nor does planning imply "not coding". You can code and plan at the same time, so long as you're not afraid to throw away any piece of code whilst you're still in the planning stage. Languages such as Python are ideal for this type of approach.

So my advice, when starting a project, would be:

1. Define exactly what you're going to do. Have a clear idea exactly what your program achieves, and what general mechanisms are needed.
   
   
2. Research tools and libraries on Google. Look through the documentation and examples and try to gauge if they'll make your job easier.
   
   
3. Start playing around with the research tools you've chosen. If they don't work out, throw them away. What you've got left should be a good base for your software to be developed on.
   
   
4. Plan out your software, using the tools at your disposal. Use whatever you feel comfortable doing; pen and paper, interactive interpreter, small 'test' programs. But remember that at this stage, you should be prepared to throw everything away if it doesn't work. It's unlikely that any code developed in this stage will wind up in the final product intact.
   
   
5. Now you can start programming.

nnxion

On big projects you have to plan, planning is everything.
There are usually 3 parts to a project.

1 Analysis
2 Design
3 Implementation

First, one does an analysis on what the problem is. One goes to the customer and asks what the problem is, one has to have concrete users to communicate with.
Second, work with the client on a solution to the problem, the client has probably thought of a solution to the problem, and has asked you to build it for him, but the solution the client has given might not solve the problem.
Third, design your solution, you can use UML or another modeling language for this. Also specify what actions will be taken, use the MoSCoW rules to define the "must haves" in your solution.
Fourth, make a concrete timeplanning, you can do this a number of ways, one is to use timeboxing.
Five, make it, most likely your specialty.
Six, test it, make sure your product works and works like the customer wants it to work.
Seven, deploy it at the customer, make sure he's happy with the solution, a good relationship will get you far.

__________________
"Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for."
-- Socrates

DaWei

One of Arevo's key points is that if you don't reinvent the wheel, you won't need to plan a wheel development program.

Actual planning, when it IS required, is nothing more than forethought; the larger the project, the morethought. It isn't common for the human brain to comprehend a complex entity in its entirety. One breaks it down into comprehensible components. If the complex entity is a plan of action then one has to understand not only the components, but the interrelationships among them. One cannot build the prototype until the printed circuit board and the components are available. Neither one of those will be available prior to the design. The design won't be possible until the requirements are defined. One must not only think of how to accomplish those various things, one must think of eventualities that MAY occur that will impact the success of achieving their completion.

Believe it or not, a good plan will give you a return on investment better than most of the investments you will make in producing your product, whatever it may be.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Eryk

Thanks guys, I really appreciate the help, as I've been having trouble with lack of planning in larger projects.