Take the 2-minute tour ×

My current state is a mixture of spreadsheets, wikis, documents, and dated folders for my input/configuration and output files and bzr version control for code.

I am relatively new to programming that requires this level of documentation, and I would like to find a better, more coherent approach.

update (for clarity):

My inputs are data used to generate configuration files with parameter values and my outputs are analyses of model predictions.

I would really like to have an approach that allows me to associate particular configuration(s) with particular outputs, so that I can ask questions of my documentation such as "what causes over/under estimates?" or "what causes error 'X'"?

share|improve this question
You are talking about input and output files (pre- and post-processed data), right? The question title made me think about tracking the numeric inputs and outputs, using a signal flow diagram. –  AShelly Oct 13 '10 at 15:31
yes, my inputs are data used to generate configuration files with parameter values and my outputs are analyses of model predictions. –  David Oct 13 '10 at 18:26
This seems to ask for special input-output tracking. Write some yourself or at least start to keep track of input-output pairs in a database and think about processing that data. –  Barfieldmv Dec 27 '10 at 10:17
@Barfieldmv I guess if there is no other solution, That is what I will have to do. –  David Dec 28 '10 at 18:19
add comment

8 Answers

up vote 3 down vote accepted

An issue tracker could be a nice way of organizing things. You can fill it with both feature requests and problem reports. Check this article from Joel on software blog: Painless Bug Tracking.

share|improve this answer
add comment

I don't think it makes sense to try and put everything into one place. There are a bunch of related things that go along with development and each can have its own system.

  1. Excel for my todo list, populated via SQL call to the awful in house bug tracker
  2. My status reports are built from my todo list
  3. The app build process is usually documented via a build.txt file in the source tree root
  4. The local app deployment info is usually documented via a deployment.txt file in the source tree root
  5. Anything that a new dev would need to know is in a README.txt file in the source tree root. This includes where the CI server is and what projects use/are used by this project.
  6. Project planning, dealing with infrastructure larger Meta-issues that deal with system architecture go on the wiki. It makes little sense to me to put build or local deployment notes here rather than with the source.
share|improve this answer
add comment

You need to ask yourself, what am I trying to accomplish. If you are trying to get better at estimating then you need a time tracking tool. If you just want to have your notes organized then use whatever method you are most comfortable with (I use a notebook). Bug tracking is obviously important. What tool depends on the size of the team, how its distributed, and if you need to report any metrics off of it. Small co-located team can use the notecard method, a distributed team needs an electronic system. I have used Trac, GitHub, Starteam, Excel Spreadsheets, and custom developed. Most important thing for bugs is it has to be easy to put them in and close them. If you are using SVN for source code, then I recommend trac because you can set it up to auto close. Github.com is good if you are using Git.

share|improve this answer
Thank you for your answer. I would like a way to track the relationship between model parameter values, configuration file content, and output. For example, to make it easier to know what I had to do to resolve a bug, or what configuration resulted in some output of interest. –  David Dec 21 '10 at 20:56
With SVN you can use TRAC for tracking tickets. They have a mechanism to integrate with SVN. You just put the ticket number in the SVN commit and it will sync up. I just switched to using github and I am sure there are tools there, but I haven't used any yet. They have a ticketing system and wiki built into github. I would think you could tie a commit to a ticket. –  Bill Leeper Dec 28 '10 at 19:21
add comment

We're a big fan of 37 Signals' Backpack. It's very flexible and allows us to continuously improve how we document our projects. Campfire (also from 37 Signals) is also a great tool and their primary project management tool.

share|improve this answer
add comment

Our team uses 3x5 cards of various colors taped to a whiteboard.

It's big and visible, and extremely flexible.

The documentation that we leave behind is a comprehensive set of unit, integration, and functional tests that explain what the software does, and demonstrate that it works.

share|improve this answer
add comment

Google Wave is a good solution.

It is version controlled, multiuser, remotely hosted, free, you can color code, make diagrams, export documents etc...

share|improve this answer
Isn't Wave going away? google.com/support/wave/bin/answer.py?answer=1083134 –  Eric King Dec 21 '10 at 20:40
Is not. It's been open sourced. –  Mchl Dec 28 '10 at 15:05
Right, the source code is being put out there. But Google Wave, the hosted by Google version, is going away. Some day in the nebulous future, you may be able to install and host a version for yourself. –  Eric King Dec 28 '10 at 15:52
A self hosted version sounds better in some cases anyway. –  Petah Jan 29 '11 at 11:55
add comment

first i have white boards behind me ( three ) with the flow and instant progress overview second i use trac for resource management http://trac.edgewall.org/

share|improve this answer
add comment

There are a lot of good answers here, but none exactly met the need.

What you are looking for is a 'workflow management software', specifically a Bioinformatics workflow management system, I am using Kepler at this point, but there are many others (e.g. Taverna, CyberIntegrator) listed at the wiki link above.

share|improve this answer
add comment

Your Answer


