

Ask YC: How do you handle development planning - brentr

I've never worked on a project I couldn't fit into my brain all at once. Now that I have an idea for a large development project, which I hope to eventually take through the start-up process, I have started to research different development methodologies.<p>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.
======
vikram
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.

------
bigtoga
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!

------
matthewking
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.

------
xenoterracide
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.

~~~
haasted
... and you just cost me 20 pounds. :)

Looking forward to reading it.

~~~
xenoterracide
well hopefully it's worth it to you.

------
swombat
Get the Pragmatic book: "Manage it!" It includes some good sections on
planning.

[http://www.amazon.com/Manage-Modern-Pragmatic-Project-
Manage...](http://www.amazon.com/Manage-Modern-Pragmatic-Project-
Management/dp/0978739248/ref=sr_1_8?ie=UTF8&s=books&qid=1211125323&sr=8-8)

Daniel

