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.
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.
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.
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!
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.
If you use Rails, any recommendations for CI? Thanks for the comment.
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...
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)
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.
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.
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.
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.
See: http://mortenjust.com/2010/04/19/a-wireframe-kit-for-google-...
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.
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 :)
- 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)
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.
