[Kandayo]

How do you plan your programs before you actually start to program. Whenever I jump right into creating a program, I get somewhat lost and I do not think that this is a good sign. I would like to change my habits quickly.

Are there certain or popular ways to pre-plan programs? Are there any articles on the internet that I could read? Anything that would help (even a little).

Thanks

[DaneAU]

Have an idea what you want to achieve, then using pen and paper map out your program visually. Next write some psuedo code and identify what you need to do, then being programming. At least thats what i tend to do

[stev3]

whiteboard for me

[JackOfAllTrades]

I'm going to move this to the Software Development forum, where it's more of a generic development question.

[zombie_chan51]

Drawing a quick sloppy flowchart in my notebook.

[Aeternalis]

I like to list the features of the software first. Once I have a good list of features, I think about how they should be accomplished, what they should look like, and how the user will interact with them.

My next step is to get a prototype up and running. (this is not a complete program) just a piece of code that runs and will be the skeleton of the software. It might look like a main menu or a beginning screen.

After you have a skeleton, I try to flesh it out with features. I add the features one at a time, making sure each one works before moving on to the next one. If another part needs to be added in order to finish a feature.. I go ahead and add it, then finish off the feature, dont leave it unfinished

Also, if there is a part of the whole thing that your not sure you can do.. try doing that part first. It's the risky part, and you dont want to work on the program a long time only to find out at the end that the part of the program that is risky . can't actually be done.

make sure the program compiles and runs after implementing each feature.. maybe look at doing some testing ..

Also, if one feature seems too big to implement, maybe it is.. try breaking it into pieces and implementing each piece separately.


This is called an iterative approach. Because you iterate through the cycle of implementing features over and over until its done.

There is another design model called the Waterfall method. This is a bit older but can be effective. The approach is to design your software up front before you start coding. Draw diagrams of how it will be implemented and use the design drawings to code from. Drawings may include a top down diagram.. this basically starts as a picture of the entire system. for instance movie ticket point of sale software: this might show the major systems of printing tickets, reserving tickets, and selling tickets. those are all the parts that make up the system. Once you have all of the parts of the main system identified.. then drill down to the next level.. take the printing tickets system and break it down into what makes it work: The printer interface, producing the ticket image, print spooling ... whatever makes up the printing of the tickets. after that.. you take each one of those systems and break it down into how it works..

at some point you will reach the point where implementation is what you are writing instead of parts of a system. Once you are there.. you use these diagrams to help code the project. Now the same thing can be done with other diagrams..developing the diagram to define the system and then using the diagram to help code. You can find good information about the industry standard UML :
Here


I hope this helps you get started in the right direction. Do some reading if you really want to get better at software engineering, or even better yet.. take some classes on it. Nothing beats a quality education.

Aet

Edit:: forgot about the thread.. see PsychoCoder's post below!

This post has been edited by Aeternalis: 10 August 2009 - 11:36 AM

[PsychoCoder]

We had a thread that discusses what's people's design process is like. Have a look and see

[Pwn]

My favorite way to program anything is to have an idea on what the program does, then sit down and start programming. Since I'm a hobbyist at this point with no deadline to really dictate my style, this works for me. It's more conducive to learning, as I'm free to explore until I find the right components to do what I want to achieve.

If I were in a professional setting, this might not be the most productive method, but with luck, if I ever get to that point I should have a good intuition on what I need in a program and making a quick plan to go by should be a snap. A good plan still isn't set in stone and is subject to change, so it just gives you direction while you're still doing the same basic exploration, just in a more specific direction.

This post has been edited by Pwn: 15 August 2009 - 06:23 AM