This argument gets thrown up by someone nearly every time documentation gets mentioned.
1. Does it matter if not entirely accurate with the as-is? It showed the previous state or intention, that is typically very useful and a lit better than nothing.
2. Your unit test are out of date when your change code yet that typically gets updated, or new tests added, and is typically more work than updating the docs.
3. If what you document is so wildly different to the solution, you're probably documenting too much detail (this is where most junior devs go wrong), if it's that your arch has actually radically changed it sounds like your documenting too early, do you do spikes etc to figure out your arch before you commit to it?
This argument gets thrown up by someone nearly every time documentation gets mentioned.
1. Does it matter if not entirely accurate with the as-is? It showed the previous state or intention, that is typically very useful and a lit better than nothing.
2. Your unit test are out of date when your change code yet that typically gets updated, or new tests added, and is typically more work than updating the docs.
3. If what you document is so wildly different to the solution, you're probably documenting too much detail (this is where most junior devs go wrong), if it's that your arch has actually radically changed it sounds like your documenting too early, do you do spikes etc to figure out your arch before you commit to it?