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)

It's interesting that you build your models first. This has been the way I've worked, but has felt clumsy so far on this project - hence my asking of this question. I do like the idea of controlling the models entirely from the console before building any UI though; that's definitely interesting to me as I can continue to develop the models to fit use cases that I find (I will be able to speak with a potential customer in the coming week so I'm hoping to glean more insight then) and nothing at all is wasted.

I am also not that visual, I do find it easier to fit the jigsaw together mentally, but I like to get this down somewhere solid where it can be reviewed/altered. Also, my memory isn't so great and in the past I have forgotten realisations that I'd made regarding faults in my design or changes that I should make.

Thanks for your insight; I'm edging towards the idea of modelling directly in Rails migrations.

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

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.

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.

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.

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.

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 :)

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.

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.

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

If I may; http://blog.yipgo.com/2010/12/getting-started-with-right-too...

If I may: http://www.continuityapp.com :)

Thankyou very much philjackson and stefanobernadi, interesting & appreciated links :)

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

Didn't know about this. Thanks!

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)

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.