Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

I've been learning programming on and off for the past 3 years never dedicating any meaningful amount of time until recently. Something that has confused me about programming is: How do you start writing a program or an application? I.e. more than just simple code pieces.

Do I just

  • write and refine the code as I go?
  • or do I plan the architecture of the code before I even start it, like this class goes here, this method here?

Edit: For clarity, I am not asking about coding conventions (such as proper commenting and format) but about how a programmer approaches a new project.

share|improve this question

marked as duplicate by gnat, Glenn Nelson, Karl Bielefeldt, MichaelT, BЈовић May 22 '13 at 6:31

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1  
I have rephrased your question a little to make it more accessible to readers. Hopefully I have not distorted its meaning. –  wirrbel May 21 '13 at 20:45
    

3 Answers 3

Basically there are two approaches to this question:

  • bottom up
  • top down

They both have their own virtues and can lead to different program structures.

Bottom-up programming is basically about starting to write a program and extending it more and more until is actually does its purpose. top-down programming is about carefully layouting the overall structure of the program and then implementing the details.

Top-down programming needs a fair amount of understanding about the overall structure of the software. Software Patterns have been established in order to avoid common pitfalls and guide the architectural planning into the right direction. Top-down appraoches usually work with Object oriented languages, such as Java, C#, OOP-style C++. Having a plan about the general layout of the software, the remaining work is implementation of the details which can be divided among several programmers. Defining classes and interfaces like java-style OOP encourages simplifies Top-down programming.

Bottom up programming is not free of planning, however you start of writing a central function to your problem by thinking of "the" (or at least one) central task your program has to solve. Then you start implementing auxiliary functions in order to break your problem into smaller ones. In bottom-up programming the aim is to write small one-purpose functions/procedures that can effectively work together to do the whole task. Paul Graham has written an introduction/motivation for bottom-up programming: http://www.paulgraham.com/progbot.html

Bottom-up programming is really common with Scripting languages and functional programming languages. Top-down programming rather with statically typed Object oriented programming languages.

share|improve this answer
4  
It may be added that virtually nobody does either this or that - it's always a mesh. –  Thijs van Dien May 21 '13 at 20:47
    
agreed. I still think that pointing out those two "poles" of the continuum is really beneficial, especially for beginners. A lot of tutorials and books just take one side and do not mention the other technique. –  wirrbel May 21 '13 at 20:49

Do I just

  • write and refine the code as I go?

Yes, this is usually what new programmers do.

  • or do I plan the architecture of the code before I even start it, like this class goes here, this method here?

This is what you do after you've tried the preceding method for a while and decided that there must be a better way.

There are a lot of different methodologies because there are a lot of different programmers, and they don't all work best the same way. That said, jumping right into the coding phase is a sure sign of inexperience. Whenever you've got a problem to solve, it pays to develop an understanding of the problem and a plan for solving it first. It's easy and cheap to make big changes to a newly-hatched plan; making big changes once you've written a pile of code is not so easy and not so cheap.

Usually, you start off with some sort of determination of the requirements. This might be a written document that completely details all the required behaviors, or something as simple as a page or even just a paragraph stating the problem, goal, and approach, or it might be something in between. What you choose to do here depends on who you're writing the program for: a contract project for a government agency or a big business will usually need more detailed requirements than a hobby project that you're doing for yourself and your friends.

Once you have an understanding of what you're going to write, you'll develop a plan of attack. Again, that could be a detailed implementation plan with all the interfaces specified, it could be a diagram on a cocktail napkin, or it could be something in the middle.

Setting up a project is another step that you should tackle before you start writing code. Some time spent thinking about the process of how you'll manage the code at the beginning avoids problems later. How will you manage different versions of the code and products, keep track of bugs, make sure you're sticking to the requirements, and communicate/collaborate with others? This doesn't all have to be done at the outset, but it's helpful to at least have a plan.

So, there's a lot that you should at least consider before you really get rolling with your IDE. You don't always need a super-refined process, and too much process can hold you back as easily as too little. Worrying about getting every detail of the architecture perfect before you write a line of code can be as debilitating as being stuck with a pile of poorly considered, difficult to manage code. Just remember that the process -- the planning, tools, documentation, etc -- is supposed to help you build a better product.

share|improve this answer
    
Agreed, sorta. CS teachers always drilled into me that code should be planned before you start on it. HOWEVER...Often, before I commit to a project, I want to find out what's theoretically doable, and what systems might actually work for it (or, hit a hard exception and force me to start again). I don't want to build my systems around ideas and concepts I'm not sure of yet. Good luck doing that for your first game engine when you're just figuring out how matrices work. I guess it changes once you have a large wealth of experience. –  Katana314 May 22 '13 at 0:10
    
@Katana314 If you're just figuring out how matrices work, it might be a good idea to use someone else's game engine for a while before you write your own. Reusing existing, well-tested code is a great way to simplify your project, thus reducing the amount of detail you need in your planning. –  William Shakespeare May 22 '13 at 0:30
    
Working out the code of an existing game engine is a ton of work for a beginning programmer - for production material, that code makes sense, but there are numerous levels of indirection for the actual core code at a time when someone's just trying to figure out the basic, straightforward rendering logic. A kid's first game engine might actually have direct array references to each type of entity, but that's fine for basics; you NEED to have incremental steps to understand the "why" behind something like a Scene Graph. –  Katana314 May 22 '13 at 0:47

Are you an engineer or an artist? Or a little of both.

As an engineer you want to do planning and testing. However, software is fluid so you can get feedback rapidly. Plan a little, test a little, code a little (yes, test first, then code).

As an artist, software is fluid. I think of it like writing a book, perhaps a novel. You have a few characters that you want to develop, ideas for plot lines, and maybe a few chapters. The development of the story is non-linear, but eventually fits together.

Testing is key to developing code. Testing let's you build parts of the code in small chunks that can be individually constructed. Build many test programs around a test system (e.g. google test). This let's you evaluate how the code/object/function should work before working on how it integrates into the larger application.

Most important, have fun, and enjoy what you are building!

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.