I'm interested in starting to properly design my software on paper before I ever start coding. What is the standard approach for this?
I'm thinking something along the lines of UML but I feel that it's a bit overkill for a one-man project.
What are some of the things professionals say is best to do when developing hobby projects?
Anticipating the votes to close as usual, this isn't argumentative. It's a clear cut answer, and I'm expecting something established. :P
There is nothing like a mini-notepad inside a jacket pocket, to mind dump as soon as possible, I personally switch between mini-UML and dot points. Quick, Simple, Always Accessible.
edit: And I always have a page/area dedicated to specific use cases and actions. This allows me to come back and check if the system can handle each of these.
Some of my "tricks":
I first use mind-mapping (e.g. MindMeister).
Then, I find the probable "difficult spots" and do some lightweight prototyping
For this kind of thing, I usually sketch out the basic UIs, chart out (boxes on paper) a domain model and a database schema. I always start on paper and then if I feel it is necessary I export to visio/basalmiq.
I try to split the problem usually into two different issues:
For example: when searching for the cheapest car inside a set of possible cars, I'd identify 'cheapest' as something that probably wants to be a separate function, as I may want to change the conditions later, or apply it to SUVs as well, and 'car' and 'set of cars' sounds like good candidates for classes that I'd need in the problem domain.
To establish those:
Eventually I move from drawing those relationships further to pseudo-code and small prototypes to play around and learn what other unknown constraints appear in the problem description.
i find sketching out the UI first is very help in finding out exactly what functionality is required. Then I like to make a list for each UI element and what it should do. Once this is done I generally write out a database schema...
This is the order of how I do things:
1) Write a pseudocode in pencil. This where you can brainstorm ideas with yourself and others if necessary.
2)Write the algorithm outlining the objectives and how you will go about accomplishing those objectives.
3)If the project is small, simple and clear to you, you can ommit this step. Else, draw up a flow chart of th application.
4)Lastly, Start coding using your algorithm and flow chart as your guide.
It is largely depends on number of things and the most important one is what are you making.
1) The first step to me is to declare what are you making. Sound, simple? sometime is not. List down what you want the program to do. List what is the must-have, what is nice-to-have and what is ok-to-have (not much trouble to include).
2) The second step is to (at your best) identify what is the weakest link for the success of your project. If you are writing WebDB, what you should worry is web UI (transition from a page to another) and data model. If you are writing game, the rules of the game will be important. Or if the game is highly interfactive, then you should think of the interaction the flow of the game.
What you identified here is what you should spend time design it on paper.
Since identifying that will likely to require experience and you may not have (if you do, you will already know what to do, right :-D), you may come back to review it once in a while as project progress.
3) To avoid over-engineering, focus on modeling for understanding as oppose to modeling as documenting.
4) Once you understand more, try to create a small program to check if it is possible. If you, identify other critical but risky part.
5) Start small but always think about extension. To me, it is OK to think big but it is risky to do big.
Those are what I do. Hope it will give you some idea. :-D
In my opinion, you should stick with your final goal, In most cases, the final goal is to deliver your result to your customer, your boss, your colleague.
so all you have to do should be consistent with the goal. release it and deliver it.
I don't think designing on a paper is a good idea, it made you too lazy to do some practical work. Actually most project was too late to enter into coding phase, many stupid designers or architect were arguing the details that never existed in the war-room for a few weeks. they delayed the project.
actually you should learn more thoughts about test-driven development, it doesn't mean you should completely follow the mode, it is a thought to teach you how to effectively commit yourself in deliver the results.
Finally, I think test-driven is the most effective way to keep your commit into delivering qualified results to customers.
For simple program, I will use paper and pencil to draw a sketch of its UI, make some annotations on it. It can help me to clarify my idea and confirm my design.
If the program is bigger (more like a complete product I mean), you may need to collect some feedback from others, since one man's thought can not cover everything. The hand drawn sketch still works, invite more people to review it and give you some suggestions, thus you can polish your design a lot. However if your friend is not around you may need to fax the papaer sketch to them (or maybe scan the paper sketch and send via email).
There are some tools that can help you to create UI prototype, some of them even allow you to run simulation of the UI (like Axare and ForeUI), that will be very useful to collect feedback from others.
I am a big fan of using SketchFlow to create wireframes and mock ups which really helps the over all design process of web/desktop apps. You can see it and touch it and prove that your ideas will actually work. I also like the mind-mapping (MindMeister) mentioned else where. Lately I try to avoid BDUF (big design up front) specifications these days!
For small code projects I like to just go in and code a version 0, create all the classes I think I'm going to need and try and somewhat get them working together. I then stop and start over completely. This usually creates a much better project.
I'd use UML not because it's the defacto industry standard but because it helps you organize and document your thoughts as you explore a domain (whether personal or business). A free tool is ArgoUML.
I'd mock UIs as another aid in figuring and communicating what you think you'd like to do in your system. A great free one is Balsamiq Mockups.
And I'd focus on behavior first and data last. See Rebecca Wirfs-Brock's writings.
Best of luck! Mark