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 i

Answer 1

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.

Answer 2

Follow your heart.

Answer 3

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 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

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 6

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.