How much process should a single developer follow? Is a formal process too much?

Question

Since I didn't do a good job writing the last question, and most of the answers were good, but not at all in the direction I intended for the question to go in, I deleted it and remade it as this question.

I'm a solo developer on my own projects, generally very small things, but I have a few ideas that might turn into FOSS projects. I believe in documentation (to varying degrees, depending on the specific project and the end user), source control, and project management (including bug tracking, time management, and so on). However, I'm not sure how much of a formal process I should be following.

Perhaps just keeping a README, associated design/requirements documents, and in-code comments under source control is sufficient. Or maybe there's an agile process that is suitable for a single developer to follow. Or maybe I should take an old-school waterfall model for each project.

What kinds of processes exist for or can be adopted to a solo developer, if I even need a formal process?

---

EDIT: I realize that there are tasks that I'm doing to be doing like documentation and source control. However, I'm not sure about the how part of the question. As a solo developer, should I adopt a more agile approach (if so, which "branch" of Agile - XP? Scrum? RAD?) or a more conventional approach (waterfall or spiral?)?

Answer 1

Even if you don't need process to promote good communication between team members, process can help you compensate for the fact that you aren't as superhuman as you thought you were when you were 18 :) The type and amount of 'paperwork' you decide to do depends on your own strengths and weaknesses. Bad memory? Write down your designs and thoughts daily. Good seeing trees but not forests? Make sure you are extra careful with your requirements and designs. Good seeing forests but not trees? Detailed task lists, time estimates, and frequent deliverables are your friend.

It boils down to: what are you likely to mess up, and which processes help with your particular way of working.

Answer 2

Follow your heart.

Answer 3

Remember that while you may be solo now, those projects may become successful enough that others join you. So while you may not need all that extra stuff now, eventually you might wish you had some design documentation and instructions for building things, managing the source code repository, etc.

Also remember that those "other people" may be you in a few years, when you have forgotten everything you know now. (You're young--you don't know yet just how quickly memories disappear.) So think of what you'd like to record for the benefit of your future self.

Answer 4

You definitely need a process, there's a lot of non-code data that goes into managing and supporting a project. Without a process you'll be suffering quickly, re-hashing design ideas because you forgot all those good reasons for not doing something or re-learning how to branch svn b/c you only do it once a month.

Documentation about design, design decisions, operations, etc is all vital for any significant project.

And testing, source control, etc are all good development practices and should be done regardless of the project size.

Answer 5

This is a very broad question, but perhaps I can help by sharing an experience of mine. I worked for almost 5 years on a hobby game coding project with a couple of friends of mine. A very thightly knit group of developers, we usually tugged our machines into a single apartment for a weekend to develop the project. My point here is that it could be compared to a single person effort, as we were all there to decide on the important design decisions, and so on. 'Process?' No, none I can identify, even in retrospect.

The one thing that kept the source in control was following an 'agile developement' paradigm which we decided to implement from the start: refactor mercilessly. We did, and holy hell did it break the whole game apart all the time. But it did keep the source clean, and when we decided to go for 'stable releases' every now and then, it all seemed to come toghether.

Answer 6

Referring the page you linked to - I say follow the processes. I am a solo dev and I follow these processes. You can't write software without knowing your requirements and pre-requisistes. As others have said, get to know how you work and your strengths & weaknesses. Also, sometimes you'll get stuck & get for a little outside help. Nobody knows everything.

The whole process takes time (often never ends) and I have killed far too many brain cells over the years to store every detail in my head. Mind maps, flow charts and things like OneNote are good for non-coding long-term memory. Try to keep the bulk of it in one place or at least linked together so you don't have to try to remember where to look for it.