Post History

Source: https://writers.stackexchange.com/q/33255
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/

The deadline is looming and someone realizes the product can't be shipped without documentation. Once the product leaves the remit of the software engineers (who obviously only ever write wonderful code) and is passed on to a more objective audience an obvious design flaw is discovered. May be the [password is being sent using GET](https://security.stackexchange.com/questions/30754/is-there-a-difference-between-get-and-post-for-web-application-security), maybe the so-called REST API is [inherently stateful](https://stackoverflow.com/questions/3105296/if-rest-applications-are-supposed-to-be-stateless-how-do-you-manage-sessions), maybe there is just some kludge which makes loading the data very painful.

Anyway, there is no capacity to change the code to fix the flaw before the deadline. Something must be shipped and documented _as-is_. The engineering team will have to fix it with a patch in the next version.

What is an effective strategy for documenting such a product? Should the design flaws be highlighted or ignored?

Original score: 17