[tikiman163]

I'm not a huge fan of writing a ton of documentation about the code. I am a huge fan of requiring developers to write in-line comments explaining what they're doing so the next person can build that internal model more easily. There should be some documentation about the system, but this is much more helpful if it only explains how to get the project running locally, including configuration settings and how to interact with it (if data has to be uploaded for a process, what should the data look like and how do you upload it). From there, a mid level developer should be able to locate the code entry points and follow the online comments to find what they need.

Just because it seemed obvious what you were doing and how things worked while you were writing the code doesn't mean it is, or that it will stay that way. Especially if that code ends up getting abstracted out. In line comments demystify code for the next guy way better than any amount of well written documentation.

As for what they're making you do with the RFC documents for changes, try writing your stuff as an ordered multi-tier list. The first tier should be the "manager" description of the change. The next level should be the more technical description of changes. The third tier is the location in the code where that change needs to be made (like a file path sort of thing, but you could use name spaces and even method names if you want). The forth and final tier if you need it would be cross references to other related items in the list and implementation notes/challenges specific to the file path. I've used this approach in the past myself. It's much faster, and it allows you to write a spec doc that isn't a huge waste of your time because it allows you to half write your code at the same time. It also provides a sort of semantic map from how the manager thinks about things to how you think about them, making it much easier for a manager to discuss it with you without having to write nearly as much.

Another benefit to this is you can often use stuff from the second and forth tiers to add in line code comments.