Possible Duplicate:
What to plan before starting development on a project?

I was wondering when you start developing a software what process should you generally go through to do it?

By this I mean after you get an idea, do you just sit down and start pushing out code directly, or is there some planning process that you should generally go through first? (i.e. flowcharts, diagrams etc.)

Just wondering because I just had an idea and am about to embark on my first "real" application but have no idea where to begin. What would you suggest is the steps that should be taken to have a successful developmental cycle?

  • I'd tell you what I learned at university, but our final exam consisted of regurgitating the 30 step workflow in correct order using the exact jargon and phrasing, and needless to say, I don't remember any of it. I don't recall that we'd ever learned a name for the workflow either, because my prof was so bigoted that she thought it was the way to develop applications, not a way, and thus that it required no distinction from other methodologies. – Rei Miyasaka Jan 7 '12 at 4:15

Software development is a skill that is learned through study and practice. I would suggest you stop and have a think about what it is you want to achieve before you even begin to do more than sketch out your idea. If you think you can go from zero knowledge and experience to writing your first killer multi-million dollar app then you'll be in for a lot of disappointment.

Your question itself suggests to me that it's likely you've never written any software before. Therefore the key to turning your idea into working software is to start by learning the basics, and then take that experience and apply it to your product idea. You have to start small. It may well be that your idea has elements to it that can be developed separately, and that may be good as a means to help you progress your project and give you the motivation of working on your own idea for yourself. The flip-side to this however, is that it is only with experience that a good software developer learns how to recognize how to break out project elements into modules, and sub-projects etc.

You'll need to be highly organised, and highly motivated, and you're best bet will be to find someone willing to act as your mentor. Someone you can trust your idea to so that you can ask questions that go directly to the heart of the problems you will encounter while developing your software. You should also read extensively. I'm not that convinced that the best software engineers come out of the university system, and most of the best programmers I have ever worked with were self taught, but they read extensively, and are always experimenting and highly critical of everything they do.

I'd suggest looking into Behaviour Driven Development as a guiding process, as it will teach you how to write software in a way that is consistent with most agile development systems used nowadays, and if you stick to its principals, you'll make a lot less process-oriented mistakes going forward and your efficiency will also receive a kick from day one. A book that you might find helpful would be Head First Software Development, particularly if you find yourself needing to work with others, but also as it covers the basics well, without attempting to lock you into a specific development methodology.

Good luck.


An application is really nothing more than a collection of actions realized in software. The simplest application would have one action (e.g. "list all the individuals in the club in the browser"); more complex ones have more (e.g. "add a new member to the club", "remove an existing member from the club", "promote a member to the rank of president").

You should at least have a clear enough idea of what you want to do to be able to list out all the actions you want your application to perform. If you can't write them out clearly in your native language, it's unlikely you'll be able to write them in software.

You should make some rough decisions about how you want go about it. Who will use it? Is it a desktop app? Mobile? Web? Command shell, text driven? Batch?

How will you persist data? File system? Relational database? NoSQL? Something else?

Sketch out the main components. Some people like UML, but boxes and arrows are sufficient. A rough mental picture that's easy to keep in mind is helpful.

Once you have those, start coding. Take small bites: Write some code, test it, put it aside, work on the next piece. If you can write all the pieces to accomplish one of your actions, test it out and move onto the next one.


It really depends on how big the application is going to be. However, if it is a "real" application, it wouldn't hurt to do a little pre-planning. First, identify the major components of the application, and try and establish a rough interface between them. Next, develop each major component independently, utilizing stubs to test them. Establish that each one works as expected given the interface / public API. Then hook everything together, and verify the application as a whole.


One of the main arguments for Behavior-Driven Development is that it force you to think first in terms of user stories, scenarios, and features. Writing the tests first is a great way to organize at least the behavior of the application before you dive into building it.

Paul Graham advises diving right in rather than doing a bunch of planning for programming projects of any complexity. While this sounds counterintuitive, building a prototype that you intend to throw away is one of the best ways to understand the problem domain before you get attached to a specific model.

My general methodology for a significant or important (at least to me) project is:

  • Develop the prototype to understand the interactions and have a sandbox in which to experiment
  • Develop a basic feature list, with implementation ideas based on my prototype
  • Write unit tests, then code to the tests
  • Red, Green, Refactor.

Sketch out your UI and list some of the things you want the application to do. Start building the application or you'll get stuck in the planning mode. When you run into problems, consult and SO site.

Your first app isn't going to be perfect. Try to observe a potential user working with the application sooner rather than when the whole thing is completed.

Get in the habit of using source control.

It probably won't turn out the way you intended - that's usually a good thing.