
Ask HN: How do you begin to build your new project? - cmontgomeryb
I'm embarking on my first "decent-size" project - I know that's quite hard to define with the large variety of HNers.<p>It's a Rails app. So far most of my planning has been on paper, which I like as it is very quick, accurate and I can do it almost anywhere.<p>However it's hard to edit (pencil/eraser is fine for small areas - but what about moving large parts of a layout/diagram), impossible to search and not backed up anywhere.<p>So how do you guys do this? I have tried Visio, Gliffy and one or two others for loosely "UML" diagramming - just to get models and their relationships down, but I can't find anything I get on with.<p>Bonus question; what is your guys process for beginning a new project? Do you plan user flows/stories and base your models around those interactions? I'm looking to learn from you guys and your experience so any info in this regard would be fantastic, thankyou!
======
cubicle67
I work full time, so my projects are done in evenings, on the train etc.

I have an A4 sketch book and pencil I carry with me pretty much everywhere.
Ages before i start coding, I'll be sketching out idea after idea for the
project; everything from screen layouts, data flow, bits of text (If a good
idea for some working comes up), names, db design etc. I've tried doing this
stuff in software, but nothing comes close to pencil+paper for me

These drawings/notes aren't means as permanent artefacts, but rather as an aid
to helping me think through the idea and flesh it out. As I build up the idea
I spend a lot of time playing with it in my head (I'm very visual and seem to
have a good ability to mentally model things)

When I have a few hours free, I'll start coding, but then often only until I
find the next thing I hadn't considered and then I'll head back to the
sketchbook.

When coding, I start with the back end process first. I also use Rails, but
I'll build my models first, and I make them so I can control them completely
from the console. I don't start building the UI until I'm happy with the way
everything sits together.

Then, once things are nicely underway and most of the major problems are
sorted out I'll lose interest and start on something new (actually, at any one
time I've usually got a minimum of 3-4 project somewhere in their lifecycle
between initial enthusiasm to abandonment)

~~~
swah
Wow, nice twist on the last sentence. I have that problem too: the project is
no longer a challenge and so its not interesting.

~~~
linked
It's not a "problem", it's a gift.

Engineering the project is the hard part, but for a lucky some of us, it's the
_fun_ part. "Polishing" your project, on the other hand, blows. Who wants to
spend the day building flow for user account cancellation or tweaking the
registration page, when you could be optimizing code?

The win-win situation here is clear: Do the engineering that you love & pays
the bills, hire cheap talent to do the cheap, boring parts. Because, at least
speaking for myself, if I'm being honest a $12 hour designer would do these
"menial" jobs _BETTER_ than me.

------
ra
Here's how I get started:

1\. Write down succinctly who it's for and what problem it solves.

2\. Write scattered thoughts down on a notepad, discuss with stakeholders,
consider variations on solutions.

3\. Inevitably you end up with a feature list, but try to abstract those to
"customer benefits", refactor your feature list.

4\. Capture this list in a text file under version control.

5\. Draft a data model on paper / in an editor (using ORM, ERD or whatever you
are comfortable with), then walk possible use cases against the data model.

6\. Make changes to the model until it works for every use case considered
(And I mean EVERY use case, NOW is the time to play with your data model).

7\. Once that seems OK, I sketch (on paper) then build (in code) the UI for
the simplest AND the hardest use case.

8\. All of that takes relatively little time, yet gives you a pretty good
starting point without any wireframe or data modelling tools.

9\. Show it to someone (i.e. do a demo); it won't work as expected.

10\. Refactor and iterate. When the initial use case is working (demonstrated
to some one else), built a prioritised list of __new capabilities __for your
software.

... now we're started.

~~~
zdw
Exactly - to add to your #4, I start a repo for the project and shove the
entire thing, docs and all into it when I start creating anything new.

Automation here is your friend - I scripted it to create a new repo, create a
remote branch to a private git server for backup, make a standard directory
structure, etc. for various project types.

The fundamental thing about this is making a ritual out of your best practices
- the list above is a great example of that.

------
thecombjelly
I think it actually depends on the language that you use. When I used
languages based off C, that didn't lend as well to rapid prototyping, that
didn't have a good repl; I would do a lot of design work on paper. I usually
ended up over engineering things with this approach though.

Now that I think and write in Lisp, I find it is a much better approach to
draw up one or two UI frames and then code up the UI with hard coded data.
Then I just slowly build the hard coded data out and the actual app in. I
don't actual engineer much at all. I just let it flow out. This leads to a
much more efficient design process in terms of the time to quality ratio.

It also seems to me that every time I try to program bottom up on paper, I do
a terrible job at it. It works much better when I have actual code.

------
apedley
It's interesting how everyone builds their model's first.

I used to but found it less rework if you build the GUI first. That way you
build your model knowing exactly what is required.

But I too use pen and paper. Nothing quite compares to it, just yet anyway :)

------
dkubb
I know you were asking about design, but the first thing I usually do with a
new project (usually commit #2) is to make sure the deployment process works.

Then I usually setup a CI service that runs the specs on each commit, and
deploys to a staging/demo server automatically if they pass.

The reason I do this first is that deployment becomes more difficult the
further into the project you get. It's easier to work through deployment
issues incrementally rather than just before launch, or when you want to demo
the app to someone outside.

~~~
cmontgomeryb
This is something I was considering. I've never personally dealt with the full
deployment process by myself with Rails, so I was going to look at this when I
get to coding. I wasn't planning on CI, but it's something else that I'd like
to do.

If you use Rails, any recommendations for CI? Thanks for the comment.

~~~
fhirzall
You could run something like Autotest for continuous testing & quality
control: <http://ph7spot.com/musings/getting-started-with-autotest>

You can run Capistrano for continuous deployment:
<https://github.com/capistrano/capistrano>.

If you wanted to go the extra mile you could also setup different staging
environments on your server:
[http://cjohansen.no/en/rails/multi_staging_environment_for_r...](http://cjohansen.no/en/rails/multi_staging_environment_for_rails_using_capistrano_and_mod_rails)

------
nikcub
Most recent wireframing tool I have used is Google Docs. Search the templates
for 'wireframing' - there are a lot of good template sets for the task
(browser buttons, iPhone, etc.)

See: [http://mortenjust.com/2010/04/19/a-wireframe-kit-for-
google-...](http://mortenjust.com/2010/04/19/a-wireframe-kit-for-google-
drawings/)

~~~
veb
Didn't know about this. Thanks!

------
thibaut_barrere
My current workflow for homegrown projects:

\- brainstorming in a mindmap (for ideas); I keep it for as long the project
goes

\- sketches on paper

\- once the ideas get clearer, I use acunote to create iterations/sprints
(only what's really planned in there)

------
petervandijck
A few pieces of paper that contain classes, some UI screens, some other bits
and pieces, stuck to the wall above my monitor.

Alternatively, a big whiteboard with all that stuff next to my monitor.

Purpose is to have all the reference material available for glancing at during
coding.

