Ask YC: How do you handle development planning
5 comments
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.
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.
Pen and paper first is my approach. I like to do workflows and ideas on pen & paper with lots of bullet points and rewrites. I go off to a secluded, quiet area and turn off the cell phone/computer and then I just start writing in long hand what my idea(s) is. After that, I start thinking about what features to add in - I'm not really being discriminate yet; any idea will do - and write those down.
Once I've done the initial brain dump, it's time to tighten it up (and more coffee, please). I re-write it all trying to make it shorter and more explainable to someone else. This inevitably leads me to other ideas and again I just brain dump - no worrying about shortening it or explaining it at this stage.
Okay - take three is tightening it up further and segregating into bucket "A" (must implement in beta), "B" (must be present in version 1.0), and then I put the rest for later. I write up the summary in 3-4 sentences max.
Done with that part of the planning stage - now it's time for workflows. I figure out the major consumers - who's going to use the product? I then create a page for each of them that describes, in minor detail, their usage of the product.
Once I have that done, I then re-write it all and tighten it up which inevitably leads to more ideas... And then I tighten it up once more.
Once I'm done with the paper part (usually several days), now it's time to prepare a mockup of the product's main features using a graphics editor. Once I have designed these, then it's time to start building.
When I build, I like to build the prototype first in terms of look/feel and then add the guts later. I'm very concerned with code maintenance here (assuming you are programming) as I know that I will rewrite this 10x in the next month and 3x in the next year. Take your time - you can make mistakes here that will be felt for years.
Good luck!
Once I've done the initial brain dump, it's time to tighten it up (and more coffee, please). I re-write it all trying to make it shorter and more explainable to someone else. This inevitably leads me to other ideas and again I just brain dump - no worrying about shortening it or explaining it at this stage.
Okay - take three is tightening it up further and segregating into bucket "A" (must implement in beta), "B" (must be present in version 1.0), and then I put the rest for later. I write up the summary in 3-4 sentences max.
Done with that part of the planning stage - now it's time for workflows. I figure out the major consumers - who's going to use the product? I then create a page for each of them that describes, in minor detail, their usage of the product.
Once I have that done, I then re-write it all and tighten it up which inevitably leads to more ideas... And then I tighten it up once more.
Once I'm done with the paper part (usually several days), now it's time to prepare a mockup of the product's main features using a graphics editor. Once I have designed these, then it's time to start building.
When I build, I like to build the prototype first in terms of look/feel and then add the guts later. I'm very concerned with code maintenance here (assuming you are programming) as I know that I will rewrite this 10x in the next month and 3x in the next year. Take your time - you can make mistakes here that will be felt for years.
Good luck!
I use GTD - basically break it up into sub projects, create a mind map of what each part will do, then forget about it all, clear your head so you can think properly and not get stressed.
You then browse these pages occasionally and pick out some tasks to put into your next actions list.
Keep at it, and eventually it'll be done, no stress, no overwhelming lists of stuff to do. Works great :)
Id suggest buying the gtd book if you're interested.
You then browse these pages occasionally and pick out some tasks to put into your next actions list.
Keep at it, and eventually it'll be done, no stress, no overwhelming lists of stuff to do. Works great :)
Id suggest buying the gtd book if you're interested.
you might like this book (I've been glancing through it).
http://safari.oreilly.com/9780596527358
Well I just spent the majority of 6 hours building a site mock up. We've done lot's of brain storming. But we don't actually have that much in structured layout yet.
http://safari.oreilly.com/9780596527358
Well I just spent the majority of 6 hours building a site mock up. We've done lot's of brain storming. But we don't actually have that much in structured layout yet.
... and you just cost me 20 pounds. :)
Looking forward to reading it.
Looking forward to reading it.
well hopefully it's worth it to you.
Get the Pragmatic book: "Manage it!" It includes some good sections on planning.
http://www.amazon.com/Manage-Modern-Pragmatic-Project-Manage...
Daniel
http://www.amazon.com/Manage-Modern-Pragmatic-Project-Manage...
Daniel
What I would like to know is how other groups manage complexity. Do you create use cases and make use of UML? Do you just start coding and see what pops out? Any help or ideas would be greatly appreciated.