I'm fairly new to programming (still a student), and I haven't had much experience with planning out my software development. Usually if it's a large project, the profs break it up into steps for me. If it's smaller, I usually just dive right in. This has worked so far, but I'd like a better process. I'm planning to do a rather ambitious project, and I'm worried that my code will turn out a mess and/or take a lot longer than if I had planned it properly. I'd like a method/technique/advice for planning out my software development.

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

How ambitious are you wanting to plan? For example, are you wanting to have the scale of Google or Facebook from day one? How long of a project are you expecting this to take, what kind of time commitment and team size do you have in mind? Those are just some of the more basic questions that would shed some light as I could imagine spending thousands of dollars or more in some grand scale project on one end and on the other wanting to build the next Facebook while only spending a few hours a month and thinking it could be done in a couple months.
– JB KingJun 9 '11 at 21:46

Where in your education are you? Are any software process and project management courses on your roadmap?
– Thomas Owens♦Jun 9 '11 at 21:54

SCRUM is applicable to all projects big or small.
– Jarrod RobersonJun 9 '11 at 21:56

4

@Jarrod Roberson Scrum is designed for teams of 5-7 developers plus supporting people, not for individual developers working on personal projects. You can't have a stand up meeting. You can't separate the Scrum Master, Scrum Team, Product Owner, and Stakeholders.
– Thomas Owens♦Jun 9 '11 at 22:00

3 Answers
3

Don't mean to offend but your first "ambitious project" is probably going to be a mess, in comparison to what you will be writing say, 5 years from now! Just enjoy the process and don't take yourself too seriously. You are, after all, still learning.

It won't hurt if you get an understanding of some design patterns and try to work your code following some kind of methodology like TDD. I recommend a book called "Code Complete 2nd Ed." by Steve McConnell.

Get a startup FogBugz account and just start logging tasks and bugs. Use it religiously and document every little thing that you do. Be realistic with your estimates (as realistic as you can) and with your prioritizing. You will learn a LOT about yourself and your planning and capabilities by using this tool (or any bug/task tracking software).

One of the biggest mistakes you can make is optimizing your code too early... Try to implement one feature at a time. Adopt Test Driven Development to build up a suit of tests around that feature as you go. The tests should pass even as you refactor and continue to build new features. I'd do this no matter what.

In terms of having it take longer/shorter, you might want to first understand where you think you are spending too much time. Break the project into a few smallish chunks you can work on and complete in a period of time where you can be totally dedicated to the project (that is, set aside 2 hours, and pic what you think is 2 hours of stuff you can complete)

At the end of the 2 hours, review (mentally) what you completed and what was taking more/less time than you thought. Review where the project is, and evaluate the rest of the work and see if you need to adjust your choices for design or implementation.

When you complete the project, ask yourself what you might -specifically- do to improve the next time. Think about the time spent researching/designing the project vs coding vs re-factoring vs chasing bugs. If you find yourself "out of balance" in one of these, decide what you might try differently the next project.

Finally - talk to the others taking the class with you and see how they are approaching the projects. Learning from your peers almost always pays off!