I want to develop a project on my own (if it is sucessful more people might start working on it too). Also I want to apply some proper software engineering from the first until the last day. On one hand just to try it out and compare results with previous projects that were just about writing code quick and dirty, and on the other hand to learn! I know the proper answer to this question is "It depends very much on the project...", "There is no single correct answer...". But I just need someplace to start, somewhere where every step is written down and tells me what to do. If I'm not happy next time I'll try something else.

So, how/where should I start? I would love to hear some book suggestions cause I'm all about books :-D.

EDIT: Answering a few of the questions that popped up:

Customer: There is kind of a customer/friend. No real pressure.
Version Control: I have used subversion in the past and want to try mercurial.
Bug tracking: I was under the impression that for s single developer a checklist was enough (am I wrong there?)
Testing: I want to try Lime (because I use Symfony) and Selenium.

On the whole I will try out a lot of stuff I haven't used before but as I said one of the main points is learning. The Pomodoro Technique keeps popping up wherever I look, so maybe I should have a look at that...


Here's the process I use for solo development:

  • Set up a version control system and a bug tracking system. There are ton of options for both. I use Mercurial & FogBugz personally.
  • Put anything that needs to be done into the bug tracker.
  • Pick a bug, fix it.
  • commit to your version control system.
  • resolve the issue.

This way you can have a clear idea of where your project is going, and a clear sense of accomplishment as you move through it.

| improve this answer | |
  • Agreed. For solo projects the most important thing is keeping organized on your code and to-do list. Most of the formal "Methodologies" are more about helping teams (i.e. multiple people) work together efficiently. – JohnFx Jan 31 '11 at 21:42
  • Most of the bug trackers are overkill, unless you have an instance running already and have a variety of tools that your used to that already provide interfacing support. I resort to the Pomodoro To Do and Inventory lists (scribd.com/doc/36672138/Pomodoro-To-Do-Today) and usually have one document where I develop the basic idea and maintain a wish list of future goodies. – Filip Dupanović Jan 31 '11 at 22:19
  • I tend to like FogBugz since they offer a free hosted installation for solo developers. – JohnFx Jan 31 '11 at 23:51

When you work on your own, there is hardly a "process" for you that deserves that name. You better concentrate on doing the programming part right, properly using version control, writing unit tests, all the stuff that makes good code good.

| improve this answer | |
  • 1
    Step one in any project: hg init hg add hg commit -m "Initial import" (git works too) – cwallenpoole Jan 31 '11 at 21:17
  • Yes sure. I'm aware that all those big development processes are for huge teams where coordination is the key factor. But I also want to learn something! I work in a small company where only version control is used and I would like to be able to show the way to some improvement. This project is my own private project though. As you know, the best way of learning is doing ;-). – Omar Kohl Jan 31 '11 at 21:31

Version Control

If there is one thing that any project needs (including sole projects) its version control.

Anything else you use is optional (but version control is a must (I wish universities tough more about the subject)).

Test Driven Development

This is nice to have as you can easily spot regressions in the interface as the code is updated. This is a definitely very nice to have working on a sole project (but not essential).

A Plan and method of tracking changed to the plan

You need to define what you want to build, how you want to build it and mistakes you have made.

If your project gets big enough where other people start joining, if you have tracked decisions/problems/errors you new contributes need not make the same mistakes or go down dead ends that you have tried.

To this end some form of bug tracking DB/ feature list/ Project WIki.

Also by having a plan written down (including what features you like (potentially with a priortised list)) you know what you need to focus on in the next stage.

| improve this answer | |

Before you type one character of code you must have a plan. I suggest you start by writing a requirements document that describes what, not how, you want to deliver. This document should be generic enough that it could be implemented in any suitable programming language, but detailed enough that you provide a domain and range for each deliverable subset. Review your document looking for inconsistencies, such as incomplete or conflicting requirements. Continue reviewing until you are satisfied with the completeness of the document.

Once the requirements spec is complete you need a plan for how you are going to implement the software. This is known as a software design document. It should outline the overall architecture of your project and provide details for each class, module, function, etc. A person reading your software design document should be able to see how each part of the project interacts with the other parts. Review and revise this document until you are satisfied with its completeness.

Once these two documents are done then you can start the actual coding process. These documents also serve to instruct new helpers on the project. A well-written requirements spec will allow you to assign a subset of the requirements to another person and a well-written software design document will ensure that those items are coded and tested correctly, and within the domains and ranges specified.

| improve this answer | |

Have you tried the Pomodoro Technique? Biggest problem with working along is that you have no colleague to keep you focused. Using the tomato might help you with that at least.

It wont make any smalltalk though...

| improve this answer | |
  • I'm really thinking about trying this pomodoro technique out. I read about it everywhere! – Omar Kohl Feb 1 '11 at 19:45

Do you have a customer? Or is this just a personal improvement project (to learn how to do proper software engineering)? The key issues with most projects is related to managing a team. I recommend you:

  • Use a code repository and practice checking in and out with coherent comments.
  • Use a bug tracking system and keep track of bugs (outstanding, in process, fixed, deferred).
  • Find a comment/source documentation system that you can tolerate and use it. I personally prefer Doxygen, but YMMV.
  • Create a one button build and do regular builds.
  • Write tests and use them.
  • Create some sort of flowchart to show the 10,000 foot flow through your application.
  • Create an object diagram that shows how your modules are interconnected.
| improve this answer | |

I would recommend approaches:

  1. Document your code so that when you come back to it than it looks something familiar
  2. Have tests written for different functionalities.
  3. Follow Agile so you can see output of you efforts in short time and doing so will give you motivation to carry on.
  4. As always, keep learning.
| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.