Single Person Application Development?

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

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.

You need to comment your code more. If you leave the code, come back in two weeks, and can't remember how the code works, you need more comments.

If I know the requirements (at this current time), do I record them anyways?

Yes, for the same reasons stated above.

how do I manage these requirements?

A feature list is OK, provided you have enough detail in each feature to jog your memory.

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

Break down each feature into smaller and smaller tasks, until you feel like you can do each task in a half day or less.

What would be a normal flow of events that one would follow?

That depends on your development style. In general I would follow a clear but simple architecture, avail yourself of software patterns where practical, and provide adequate unit tests for your code as you go.

What diagramming/modeling would be sufficient for this level?

Sufficient diagramming/modeling to make the project clear in your head.

What steps, documentation, and other project related activities are needed to help bring this project from an impractical, hobby project to something more professional?

Other than what I have already mentioned, make sure you have a good source control system and daily backups in place.

Good luck!

Answer 3

If you believe there is a chance that you're going to work on the project for some amount of time, leave it, and then come back to it at a later date...your best bet is to treat the documentation for the project the same as if you were working with a large team.

That means documenting requirements (even if they're from yourself), writing use cases (if functionality is going to be complex, otherwise some other form of documentation could suffice), and some level of UML diagraming (or other domain specific diagram) which could include activity diagrams/class diagrams/etc.

That way, when you leave the project for some amount of time, you can come back to a well documented idea and pick up where you left off.

As a side note, I try to do the majority of those things no matter what...that way if I ever find somebody interested in working on the project with me, I can get them up to speed quickly and get them on board with my ideas.

Answer 4

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.

Answer 5

This is how I work, YMMV:

• Keep a spreadsheet for high level of everything - list of your projects, and some top-level items/todos/reminders

• Create a "project" folder for each product/project you have or work on, and create a strucuture to contain documentation and code for the project.

• Keep a top-level "catch-all" document for each project, in the root of this folder. Keep you ideas, research, notes etc in this doc.

Then if you want to get organized, keep an MS project file (or similar) and plot out timelines for the various steps in each project. This is good for tracking progress on each project and make sure you arent forgetting anything. Basically keeps you honest with yourself.

And if you need to track progress on project work you are doing for clients, I understand Basecamp is a good solution for this. I am currently evaluating it for my own company. See www.basecamphq.com

Answer 6

Even as a solo developer, you should document at least the overall features of your project, and then the requirements for the particular feature you are working to complete, and then maybe produce a short pseudo-code for the functionality you're currently working on.

That way, if you do end up breaking away from that project, you can get back to it and see where you're up to easily enough. It's also pointless getting too far ahead of yourself with details for this same reason.

It's also a neat motivational tool for a solo developer - getting through and ticking things off is a way to show progress - something that you can start to feel you're not making when you're chewing through a couple of thousand lines of code and it seems like you're still miles away from actually having 'module x' completed.

Lastly - with regards to code comments - I at least try and fill out what actions/behaviour a new function should have in an outline, and then write the code in between the comments. Also, it is useful having plain English explanations of why you're branching in an if/else to support the logic in the condition...

Answer 7

I belive that better results in solo development one can achive with appropriate tools support and tasks that compensate lack of ohers people and help to organize working time. Any tool that generate metada with minimal create time cost describing your software is helpful.

• VCS and tools for tracking user actity/code changes history - very important is to add good commit messages
• mind-mapping tools for storing project related data (e.g. XMind), blacboard is useful too :)
• time tracking tools (e.g. Toggl.com)
• write a lot of acceptance test and use acceptance testing frameworks

Of course these clues also fits in non solo development :)

Answer 8

As a lone developer, I've found that your time is very expensive. This means that you have to balance sustainability and momentum - even though you are just one guy, you have to do things so that the you six months from now can go back and look at old stuff without wasting time, without spending so much time maintaining the systems that it compromises your flow.

Your question suggests that you are thinking in terms of fairly heavyweight tools and processes, but the 80/20 rule applies - for example, you can nail documentation well enough by TDD, using the doc tools of your platform to generate API docs, plus a Wiki for specs, lists, etc.

In that vein, I would suggest that you choose your platform carefully. The question about modelling suggests that you are using a platform that produce a lot of code and artifacts, but you may be able to get most of the functionality for much less management overhead elsewhere. Today I'm working on a .NET Web app that I wrote "the right way", but now realize that I could have delivered the same functionality much more efficiently in this case by using PHP with a PHP MVC framework to keep a clean structure.

Specific tools that I'd recommend:

• A distributed version control system (much less overhead than centralized)
• The most lightweight platform that you can use that has good tooling
• A Wiki to easily capture and maintain small and large bits of content
• Whatever testing framework that you can use, right from the start of the project
• A lightweight TODO list system that you can access from anywhere

Answer 9

I used to work on a very small team (one dba and one C# developer). Even then I found it very useful to have written requirements, formal tests, source control and bug tracking (we used bug tracking for our features as well as bugs). It helped us to not forget anything and a year later when you were doing maintenance, you had something to research though to help you undersatnd what you did. Plus when the two of us left (as most people eventually move on) there was documentation there for the next person.