Thread: what project planning and managment software to use for 1 person project?

Hi all.

I want to write my first app(quite small console app, probably less than 2000 lines), so am looking for planning and managemet software that will allow me to:

1. state objectives
2. associate functions with each objective
3. associate variables for with each function
4. have some flowcharting capabilities
5. manage work flow
6. relate everything.

So far I've used a word processor + pieces of paper + flowchart program, but there is no way to link and relate all the information to each other, because of separate apps and mediums(ie. paper). I don't need any workgroup capabilities, since I am coding solo.

So what do the pros here use? Any open source software?

Thanks in advance.

EDIT: Oh yes, I prefer the software to not be web-based, and have good supporting documentation.

For 2000 lines, I would suggest a large magnetic white-board.

You can doodle the design right away, and change it in a moment to be something else. 5"x3" sticky notes sub-divided into a 'T' (top is description, left for members, right for methods) make for excellent class cards. If you can't fit a class on the note, well the class is probably too big and you should split it up.

Multi-coloured pens allow you to tick off things like in-progress and done with minimal overhead.

Whilst you can get s/w to do all those steps, finding it all in the same package is going to be harder.
Not only that, the learning cost of all of that is going to put you off actually starting your app, never mind finishing it.

When your requirements are like 50+ pages of A4 long, and your UML design is half a dozen layers deep, that's when the tools really start to come into their own. But by then, you're also looking at having half a dozen people on the team as well, where each is focussed on just one aspect of the problem.

The way I am working right now, with the word processor, pieces of paper and flowchart program, if I remove a variable in the w/p, then I have to cross them out on the paper, and delete them in the f/c. So making a change in one app means having to manually make changes a few times elsewhere. This situation gets ridiculous and unworkable as the project develops, and I lose track of the relationships.

If I use the whiteboard + sticky notes + coloured pens, I think I would need to manually change things a few times too, and there is no relationship between of the sets of data. I'll probably still need to use a word proc for the concepts and ideas, and a flowcharter app, and stick the printouts on the whiteboard.

2000 lines of code might not be a reason to use management software, but I do intend to write bigger programs down the track, so I wanted to start getting familiar with this type of software now. But I do agree, learning how to use complex software like this will probably cost too much.

So I will give the whiteboard method a go. it seems like a solid first step to try. Thanks.

I would not recommend storing design documentation in a management platform. Anything a developer might need to work on the code (for instance, details about the purpose of functions and usage of certain variables) ought to be documented directly in the source code with something like Doxygen comments. It will never occur to a developer to look inside the management platform to find software design information.

I get that you want to familiarize yourself with project management software, and I think you should, but this not how those tools are typically used. Project management is about defining and meeting business goals. It does not directly have to do with product architecture.

To give an example, my team currently uses an Agile project management solution (I won't name the specific one as it doesn't really matter very much) to manage our week-to-week prioritization and scheduling. Technical details about the architecture reside in a number of stand-alone documents, each of which serves a specific purpose. The code is richly commented using Doxygen, so we can automatically generate class and method documentation as well as various graphs of the relationships between components.

The project is somewhere around 15,000 lines at the moment, which makes it a small project. A 2000 line project is a "micro" project.

Of course, the best way to learn this stuff is to play around with it. Keep at it!

Thanks for the informative replies. Good to hear from the pros.

I've had the revelation that I should code my own "management" software that can handle small to medium solo projects, that will work exactly the way I want it to work ie. handle documentation, flowcharts, and tie all the elements together in a relational manner.

So I will turn this idea into a future project.

I think you should separate design of the software with the project management of it. You can look at UML for example how to modelize your code design. Then you can try to find an appropriate tool that lets you use UML in a nice GUI.

Then project management can involve a lot of things. As suggested, to document your code you should do it in the source code. If you are writing a library you might want an external user guide just to explain how its intended to be used in a high level.

There might be cases where a software goes from UML to actual class design or allow you to add other relations like this. This can save you some time and guarantee that nothing is missed. But every tool has its learning curve, its quirks, its "gotcha" and all the other stuff which might make it harder in the end. I don't think there is a perfect answer for this. If you design your own tool note that if it has a bug and you rely on it this will transfer as a bug on your actual code. Having one thing in two places is a very (very) common way to create an issue. Assuming that your code works as it is described from an automated tool is great if that tools is perfect. Otherwise you need anyway to look into your code to be sure. My point is that don't try something too complicated and base everything from the source code.

I have been doing a lot of project management and the key for me is to document nicely in the end. Which is not something done always as people just tend to move to the next project down their busy to-do list. In between, everyone has their own way and you don't need necessarily to relate everything in writing, in your head might be enough. Think that if you have to do 10 things you can write those 10 things in a paper. But what if something changes? You need to erase and re-write it. The problem is that if you rely on that paper then if it is not written you assume it is done. Where if you check the actual work, the source code for example, then you are sure. Point being that you should document things because there is a reason to document them. If you work on a yearly project then the fact that you will have no idea what you coded 10 months back is a valid reason. To document something as you code it might not have a specific value as it simply might change the next hour.