Single Person Application Development? [closed]

Question

Hey all. I would like to get some insight on a question that I have been trying to find some information about. If you are the solo developer that is building a project from ground up, how do you manage the project? In the past, I have worked on a few personal projects that have grown into fairly large projects. In almost all of those projects, I have tried to wear the hats of all the roles that would normally be in place during a normal software development project (i.e. Product Owner, developer, architect, tester, etc.). It seems that when I leave the project for some time and come back, it is extremely hard to get back into the rhythm of what I was doing. So with that, I have some questions:

• If I know the requirements (at this current time), do I record them anyways? If so, how do I go about doing this, and how do I manage these requirements? Product backlog, features list, etc?
• If this is the case, are full blown product backlogs or use cases a little overkill?
• How does one efficiently appropriate his/her time to each respective role?
• What would be a normal flow of events that one would follow? Start coding immediately, write down user stories/use cases, then go into OOA/D?
• What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?

Basically, I was curious how everyone out there in the SO community would go about developing a project from inception to deployment when you are the lone, solo developer. What steps, documentation, and other project related activities are needed to help bring this project from an impractical, hobby project to something more professional? Any help, references, or suggestions would be greatly appreciated. Thanks in advance.

Answer 1

The most difficult part, I have found, about developing solo is that it's just tough to keep yourself driving forward. Even if you're doing this to make a living (AKA, running your own software business), unless you have pressing needs (AKA, you're going to starve if you don't make money) it can be difficult to sit down and just code.

From your perspective, I would recommend following good software practices where it makes sense to. For example, if I were a solo software developer, I would have no reason to create a collaborative development environment. All I really need is an SVN server, my IDE, and a place to record documentation (might setup a wiki or a website or something). I would personally create a realistic schedule to follow and would work on sticking to that.

As for level of effort of documentation, that really depends on you and the product you are developing. For example, I would definitely recommend recording your requirements. Unless your product is trivial, there is no way you'll remember them all and why you wanted certain ones over others. Managing a full backlog, however, can be a job in and of itself. In the solo programmer case this may not make sense.

Basically, the point I'm trying to get across (and should be followed with every project - not just in this case) is have just enough management that makes sense. The rest should be focused on the work and the development of the product.

Something else you may want to look into is reading this - Agile Programming Works for the Solo Developer. There are other, similar, articles out there. Might give you some good thoughts.

Answer 2

If I know the requirements (at this current time), do I record them anyways? If so, how do I go about doing this, and how do I manage these requirements? Product backlog, features list, etc?

I have two lists of features:

• A high-level view which states the scope of the finished product
• A list of the features which I'm implementing in this iteration

Because I don't need to communicate it to other people (yet) I tend to write down the things that I don't know about the project (if I already know it there's no need to write it down): it's when it gets too complicated, or when there are details which I haven't defined but need to define, that I start to define them in writing.

I did however try to investigate/make a business-case for the project before starting coding.

How does one efficiently appropriate his/her time to each respective role?

I did non-programmer, product-owner thinking at times when I had to be away from the computer anyway.

Apart from that, my cycle is:

• Implement more functionality
• Integration-test it
• [repeat as above]

Every 3 to 6 months I compare the new-functionality-accomplished against my estimated schedule, and then recalibrate: i.e., make a new list of the highest-priority features to implement in the next few months.

What would be a normal flow of events that one would follow? Start coding immediately, write down user stories/use cases, then go into OOA/D?

I started with working part-time or in my spare time, to make sure that I had:

• Understood the required functionality
• Made significant architectural decisions
• Written any throw-away prototypes as necessary to learn new technology

After that I was ready to start developing full-time.

What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?

I'm not using diagrams at all (except for sketches of the UI). By structuring the code, and refactoring, I'm able to know/remember/rediscover/decide which software components implement what functionality.