One of the main types of content I publish on this blog is series of posts accompanying my various side-projects. These projects usually arise from one of my hobbies or interests.

As a pretty methodical individual, I came up with a workflow for planning and executing my side-projects. In this post I’d like to delve into it a bit, sharing my thoughts, so you know what to expect with my project-related posts.

The workflow I describe here applies to the common type of side-projects. This includes building software, web application, maker and DIY projects.

Without further ado, here’s the general workflow:

1. Project high-level outcomes and goals definition.
2. If new concepts or technologies are involved – hack a quick & dirty prototype to facilitate learning.
3. Requirements analysis.
4. Project roadmap planning.
5. Implementation.

(where steps 3..5 may be iterative for not-small projects)

Each step is usually accompanied by one or more blog posts, where I share my thoughts, plans, and insights. By sharing, I hope to get feedback from the community that will help me do the best that I can.

Detailed Workflow Description

The first stage, defining outcomes and goals, is usually pretty simple and straight forward. If I have a project in mind, it is usually defined by its outcomes and goals, so this stage involves putting these thoughts into words. I found that the process of “wording” the thoughts helps framing the floating ideas in my head in a coherent meaningful way. I will usually end up with something that is much more focused than what I started with. In case it isn’t obvious, the outcomes and goals answer questions like: what will I have as a result, once the project is complete? what do I need the result of this project for? why do I want to go into this project?

Stage #2 is lots of fun! Despite being organized, I found that my usual approach is not ideal for learning new things. If I am not familiar with a technology or a concept (e.g. Django, Bootstrap, Google App Engine), then the learning process will suffer if I try to maintain high standards. And I will also end up with amateur results. Also, I believe that creating something that is meaningful to me using a new technology is the best way to learn it. In my experience, it is definitely better than taking a course, or reading a book. So when I start a project that involves something new (for me), I first try to build a crude prototype using that technology. In the prototype I will usually forgo any structure, process, organization, and standards. This works for me, as long as I keep in mind that I will scrap the prototype later in favor of a methodical rewrite. I admit that sometimes I choose a technology that I’d like to learn for a new project just so I can learn it… 🙂

Stages 3 through 5 consist a simplified agile development cycle.

In stage #3 I write detailed requirements, prioritized as mandatory, important, or nice to have.

In stage #4 I plan a project roadmap, striving for every milestone to be something functional and useful. This helps experiencing actual progress during development. I will often use the working prototype to refine the requirements and planning.

Stage #5 is pretty self explanatory 🙂

Tools

For all stages that revolve around documentation (1, 3, 4) – I usually use Evernote. It makes sense for me, given that Evernote is my central hub in the digital realm. Every project will have a project specific notebook under the projects stack. I will file all project related notes in that notebook.

For projects that involve writing code, I use GitHub. I create a repository for the project to manage the code.

More project-specific tools depend on the specifics of the project. I try to select the technologies and tools that best serve the project at hand, so I can’t say that I will always use one programming language, software stack, or IDE. I can say that it is not uncommon to see me writing Python code with Eclipse PyDev 😉

Summary

This was a general overview of my side-project workflow, that describes how I usually work on my side-projects.

See also my other post with extra technical details on side-projects-blog-posts workflows. It’s pretty meta, so consider yourself warned!

As always, I’d love to get feedback and answer question in the post comments.

I’d like to acknowledge the Securosis team, whose Totally Transparent Research methodology inspired the approach I described above.