9 Replies - 2638 Views - Last Post: 15 August 2009 - 06:21 AM

#1 Kandayo  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 48
  • Joined: 17-July 09

Planning before Programming

Posted 08 August 2009 - 09:21 PM

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 :D

Is This A Good Question/Topic? 0
  • +

Replies To: Planning before Programming

#2 Guest_c.user*


Reputation:

Re: Planning before Programming

Posted 08 August 2009 - 09:42 PM

now I have the best way is to go to the groundlevel of the program
but I saw special books for the program planing (they are big, not for five minutes reading)

but the best way which I found for now is to start from the end and end at the start, every part must be developable (every function, every group of functions) and don't mix different parts, then program is obvious and you see all of its parts

when your program can become a part of another program easy - it is good result
Was This Post Helpful? 0

#3 DaneAU  Icon User is offline

  • Great::Southern::Land
  • member icon

Reputation: 284
  • View blog
  • Posts: 1,617
  • Joined: 15-May 08

Re: Planning before Programming

Posted 08 August 2009 - 10:00 PM

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
Was This Post Helpful? 0
  • +
  • -

#4 Guest_Neumann*


Reputation:

Re: Planning before Programming

Posted 08 August 2009 - 11:20 PM

I figure out exactly what I want to accomplish. There is a 6 feet x 4 feet chalkboard in my room. I use it to get a better sense of the problem - to draw diagrams, pictures, formulas, equations, etc... (I also use it for mathematics). When I feel more confident I get a pencil and a paper and I write a pseudocode for my program. Only then I actually start physically typing a program into the computer.

I assume you are a beginner. In that case starting to type a program right away is fine. There really isn't much to plan. But when you'll start getting into more complicated programs you will notice right away that you need to carefully plan ahead.

This post has been edited by Neumann: 08 August 2009 - 11:23 PM

Was This Post Helpful? 0

#5 stev3  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 44
  • Joined: 04-June 09

Re: Planning before Programming

Posted 09 August 2009 - 04:21 AM

whiteboard for me :)
Was This Post Helpful? 0
  • +
  • -

#6 JackOfAllTrades  Icon User is offline

  • Saucy!
  • member icon

Reputation: 6058
  • View blog
  • Posts: 23,495
  • Joined: 23-August 08

Re: Planning before Programming

Posted 09 August 2009 - 07:59 AM

I'm going to move this to the Software Development forum, where it's more of a generic development question.
Was This Post Helpful? 0
  • +
  • -

#7 zombie_chan51  Icon User is offline

  • D.I.C Regular

Reputation: 7
  • View blog
  • Posts: 327
  • Joined: 16-March 08

Re: Planning before Programming

Posted 10 August 2009 - 07:29 AM

Drawing a quick sloppy flowchart in my notebook.
Was This Post Helpful? 0
  • +
  • -

#8 Aeternalis  Icon User is offline

  • D.I.C Regular

Reputation: 28
  • View blog
  • Posts: 291
  • Joined: 13-July 09

Re: Planning before Programming

Posted 10 August 2009 - 11:14 AM

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

Was This Post Helpful? 0
  • +
  • -

#9 PsychoCoder  Icon User is offline

  • Google.Sucks.Init(true);
  • member icon

Reputation: 1639
  • View blog
  • Posts: 19,853
  • Joined: 26-July 07

Re: Planning before Programming

Posted 10 August 2009 - 11:27 AM

We had a thread that discusses what's people's design process is like. Have a look and see :)
Was This Post Helpful? 0
  • +
  • -

#10 Pwn  Icon User is offline

  • D.I.C Regular

Reputation: 19
  • View blog
  • Posts: 458
  • Joined: 25-November 07

Re: Planning before Programming

Posted 15 August 2009 - 06:21 AM

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

Was This Post Helpful? 0
  • +
  • -

Page 1 of 1