Use cases and UML can be useful for communicating analysis and design. Planning is really a way to help relieve anxiety that you have about the project. As with

Use cases and UML can be useful for communicating analysis and design. Planning is really a way to help relieve anxiety that you have about the project. As with any big task if you are unsure of what is involved you might be reluctant to get started on it. But get started you must. Working code is the only way to verify progress. No one cares how lovely the UML looks on paper. In all projects momentum is everything. What you need to figure out is what you are worried about? Then think through that issue. For example if you want to get things right upfront e.g. make sure it's scalable. It's important to realize that there is no way that is going to happen in a reasonable amount of time. It's probably better to write something that works and make a promise to yourself that you'll find the time to rewrite it. So how does one get started. I always start by looking at the interface and how it's expected to be used. So a mockup of a webpage. Or example programs on an api. I try and think about what capability is this program going to give me. Some principles that others have talked about: 1: Get very comfortable with the fact that eventually you are going to have to read code. 2: Now write your code in such a way that you can read it. 3: In a reasonably big project the speed of development depends on how old you think the code is (how familiar you are with it) 4: So get very comfortable with the idea of rewriting or refactoring your code. Do realize that a uml diagram isn't actually design. It's just a way of capturing a design and a pretty poor one at that. Boxes and Arrows work better and if you are communicating a design a face-2-face session is better that any document. So make a home movie rather than a document.