Wikis work pretty well for this, provided you use them. If you can't be bothered to put together documentation as you build the software (sometimes I can't be

Wikis work pretty well for this, provided you use them. If you can't be bothered to put together documentation as you build the software (sometimes I can't be bothered), you should at least make sure to document as you troubleshoot later so you don't keep making the same mistake. We store these as "Flight Rules" for our application (or error signatures, etc - whatever you want to call them) which provides the team a single location to start their search when things go belly up. That way, when you run your post-mortem (you run these, right?) you have a place to store the error notes which eventually builds up into a really useful document. Lastly, I'd say having a team norm that when one person does something the others should also be able to test it (and therefore have the right instructions to do so) is a good one for continuity. EDIT: COuple other things that have worked: - Checked-in ".dot" file GraphViz context diagrams alongside your repos are nice and easy to update - Creating decision documents for a quick run-through of options with your technical team is a great way to run an effective process while also creating a searchable artifact for later, which is great for context / lessons learned.