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