[jklein11]

This seems like a workflow issue to me.

Writing documentation should come BEFORE writing code. The developer should know the feature that they are going to implement and how they plan to implement it before they open the IDE. I've found this keeps me from coding myself into a corner.

Obviously some things might change, and the documentation will need to be updated while implementing the feature, but then it is just incremental changes to already existing documentation.

It shouldn't be a matter of "getting" developers to write documentation.. its part of the job.

As for a User Guide, I would think this would be the responsibility of the product owner, or whoever is driving the requirements around what the application is supposed to do. The developers shouldn't be deciding what the application does.. just how it does it.

[mguijarr]

Thanks for your reply. I have another question though : how would you do if there were already a lot of undocumented code ? Would you organise a "documentation retreat" to catch up then doing as you say, documenting before coding ?

[jklein11]

Paying down the technical debt is a tricky one, especially if your application is large. If you have the cash, it might be worth it to bite the bullet and hire a consultant/freelance technical writer. Get them to build up the documentation that you are missing, and then make sure your workflow enforces that it stays up to date.