On synchronizing documentation

While reading one of Rod Johnsons books (J2EE development without EJB) I thought about the extensive documentation the spring framework supplies and how accurate and up to date it is.
Most projects have a hard time keeping their documentation in sync with the code in production. When developing new features you don’t want to spend time documenting stuff that is prone to change serveral times until it is stabilized and running successfully in production. But when the feature or module is finished there is no time to write documentation as the next story to implement is already there. So the information which parts of the documentation has to be updated gets lost and the gap gets wider and wider. The same problem comes with the modification of exisiting features. The modification is made but no documentation is updated to reflect the changes.

So the main problem is keeping the link between documenation and code and marking documentation as dirty when the code was changed. This could be done by tagging the documentation with the modules, packages or classes which contribute to the behaviour that is described. Or perhaps tagging the documentation AND the code with tags/terms (e.g. from the ubiquitous language) which form the link. And every time a changed piece of code going into release the tag would be marked as dirty, having the documentation looked at or creating an issue tracker entry with the documentation request assigned to the developers who made the change.