How do you plan small work or hobby projects?

Question

What tips to people have for getting hobby/home projects done?

• What tools do you use for designing & planning code? (Pen and paper, software, both?)
• Do you use software to plan and track your project?
• How do you choose libraries to use (e.g. to make yourself productive)?
• Are there any good books/sites on planning small projects?
• How do you decide on scope of project?
• Do you try and follow a development methodology?
• Do you plan to bring other people in at later date?
• Do you prototype etc?

People might have a different attitude to planning and design here than they might use at work. If so, what are those differences, and do they make you more productive?

Answer 1

At work, I usually have to follow rigorous methodologies and processes, so I usually just jump right in to home/hobby projects. I like start with a prototype and then gradually move into a more formal development environment once I have things figured out.

Answer 2

I'm going to define "small work or hobby project" as something that, in its initial form, would consumer maybe 10-20 hours of work at the most.

Generally I just start writing code. I come up with a good nickname (so later I'll remember what this strange code is) and use it to name the main program file.

Then I'll start off with a block comment and brainstorm what I want to accomplish with the program, and prioritize features. This is where the scope is determined, but it's a sliding scope - since I've roughly prioritized features, then I can simply stop work at any time and have a subset of the features done.

Then I'll just start in.

Most of the implementation details, library choices, etc are determined on the fly depending on the expediency of the work. Since it's a personal project, however, I'll often reinvent the wheel because it's fun, and I don't have to worry about licensing issues.

Your other questions really only apply to projects that take longer than 10-20 hours (a week or two). For projects where there's 20-100 hours of work, I'll sit down and create a formal document with the concept, main features, time estimates for each feature, etc. If I don't then I'll lose my place when my attention leaves the project for a week or month, and I'll get stuck in small issues that I really should just push past (because I want to keep to schedule)

This also improves my estimating abilities.

Prototypes are built when I can't accurately estimate time required for something, or to prove a concept critical to the project before embarking, but as prototypes often turn into projects I try to develop the prototype in a way that won't limit me later if I do use it to jump-start the project.

Answer 3

Touching on your "software to plan and track your project" point, one of the best things I ever did on some of my hobby projects was implement source control.

At first it may seem counter-intuitive since one isn't really collaborating with anyone else on such a project, but it really helps for viewing history, creating branches, doing diffs etc. (not to mention the benefits if you bring someone in on the project later on).

Answer 4

Your other questions really only apply to projects that take longer than 10-20 hours (a week or two).

That might depend how much time you have spare! :) But I take your point. Even on small projects I might a couple of hours in mind mapping tool thinking about how things relate to each other. It helps clarify your mental picture before you dive in.

For projects where there's 20-100 hours of work, I'll sit down and create a formal document with the concept, main features, time estimates for each feature, etc. If I don't then I'll lose my place when my attention leaves the project for a week or month, and I'll get stuck in small issues that I really should just push past (because I want to keep to schedule)

I think that's a good point about having a schedule and pushing past things. It's very easy to get distracted doing needless research in the internet when you could be completing something. And then completing something motivates you to continue. When real life stuff interrupts it's easier to come back to something and you have planned.

Answer 5

I try to implement some form of methodology into my personal projects, but I don't let myself be beholden to it like I might be at work. Since it's my project I pick what I like from different methodologies and discard the rest.

If I need to lay out a user interface I don't hesitate to pull out a peice of paper and a pencil. Since it's just for my personal reference paper is fine.

I do try to set scope at the beginning of a project AND stick to it. Requirements creep can still happen even if they are my own. I tell myself to get a functional version 1.0 out and then start adding other features if I still feel that I need them.

While it's not necessarily a book about planning small projects, the Pragmatic Programmer is an awesome book for all software developers. It's an easy read and each time I read it I get really excited about developing again.

(- 2 cents)

Answer 6

I really like spending hours and hours on brainstorming. There are lots of ideas in my mind and all are written down in a single project.

My project folder is very full and half of the projects aren't runnable at all, but there's the option to continue programming.

For my newest project, the TDD approach was very good. The brainstorming ideas ended up in single test cases. While developing, new ideas and new tests come up. One time, a interesting thing happened. I needed a function, there was one, I tried to use it. It worked, because it was tested :)

The refactoring component is very important in hobby projects. You have to know the project, every single class, every variable. So you need refactoring to keep it clean.

In my opinion, the small projects make fun and teach you to be neat.

Answer 7

I think formally planning every aspect of the project is really important. I've come across many hobby projects where I've underplanned and ended up having to redesign at a later stage which becomes worse and worse as time goes on. My flow is along the lines of:

• What is the aim of the application?
• Who are the target audience, if any? (this can be vital if it's for public use)
• What features do you want the application to have?
• Would there be future aims for the project that you wouldn't initially include? (this can change if you plan to grow the project)

In terms of choosing libraries I try and approach it quite logically as there's so many factors that would affect my choice such as speed, familiarity, whether or not the application should be platform independant, libraries available to the language, costs etc.

I generally use pen and paper as they're agnostic and free to how you want to express your project. It can be formalised if needs be to share with others at a later date, but I always find the initial planning stage should compose of mind-to-paper planning.

As for methodology I don't usually pick one as such, but based on previous experience and how the project evolves will depend on what methodology is used. Of course in larger more commercial projects it's important to have a fixed methodology that is strictly used, but even in my programming job we don't really stick to a methodology as it just comes naturally with what we do (testing is extremely important, and the coders get the requirements directly from the end-users). Again, it depends on your environment.

As for software to track projects I typically just use a text file with two sections, planned changes, and unplanned changes. The changes can include bug fixes to updates as sometimes they just creep up unplanned. Every time I make a change I just place it under either heading grouped by the date the changes were made. Your commit comments can also outline changes/bugfixes. I prefix comments with "UPDATE: " or "BUGFIX: " to know what kind of change it was, especially if I'm making atomic commits as opposed to project-wide commits.

Whilst personal preference has a big impact on even personal projects, I think it's important to lay down some formal methodology from what you may have learnt either in the work place or at university. The formalised approach, which may take more time, can actually make your project flow much better.

Answer 8

I like to just "let it go" when it is a hobby project trying new lenguage functionalities or using patrons or cutting edge things that usually can't use at work

Answer 9

First of all there is a difference between a hobby project I do just to learn (a new technology), solve a particular problem that only applies to me or something that eventually may be shared with others (released as open source, made available somehow else (for download or maybe a website)).

Depending on type of project my priorities may be different.

Anyway, the most important "tool" for me is version control and a wiki. Personally I use Subversion with Trac. Both are free and easy to setup. With Trac there is not only a wiki for entering personal notes, it is also a full-fledged issue tracking and project management system.

Even if it is just a hobby project I find it very useful and productive to have somewhere to enter ideas or issues I discover, and being able to assign them into categories, milestones and priority levels makes them easy to overview.