7 ms·
> When important decisions are not documented, one becomes dependent on individual memory, which is quickly lost as people leave or move to other jobs. In my wo
by jammygit 7y ago
> When important decisions are not documented, one becomes dependent on individual memory, which is quickly lost as people leave or move to other jobs. In my work, it is important to be able to go back a number of years to determine the facts that were considered in arriving at a decision. This makes it easier to resolve new problems by putting them into proper perspective. It also minimizes the risk of repeating past mistakes. Moreover if important communications and actions are not documented clearly, one can never be sure they were understood or even executed.
In my limited experience, I have not seen this done effectively in a software project. What does this actually look like when done properly? Ie, how do you store the data and keep it from becoming busy work?
- AnimalMuppet 7y agoDon't document too much. For what you do document, have a central repository with a clear organization.
- anon9001 7y agoGit is an immutable history of all work ever done on code. Take a look here: https://github.com/torvalds/linux/commits/master https://github.com/torvalds/linux/commits/master And here: https://lkml.org/ https://lkml.org/ Wikipedia does a pretty good job of maintaining document and discussion history as well. In both projects, you can pull on any random thread and trace it all the way back to its origin. And if the team (and maintainer) is doing a great job of capturing the thought process behind a decision in commit messages (as Linus does so well), then you're in really great shape.
- tzjmetron 7y agoHow well would that work for binary files though - most documents in the "corporate" world are not simple text files.