It's important draw a distinction between a "design doc" and "documentation". tl;dr: "ought" vs "is".
A "design doc", as described in the article, is a tool to help make a decision. It's a proposal. It is "ought". It describes the state of the world at a point in time, the desired change, and how to make it. Once the decision is made and the work is begun, it's rarely updated.
"Documentation" is just the state of the world (generally "now" or "at release x.y"). It describes the design and use of the system, but has very little digression into ways it could be different. If it links to a design doc, it should be for
Once you draw this distinction, it's clear that design docs should be in something like Google Docs, while documentation should be in something like a wiki or git. It's clear why it's fine for a design doc to be out of date, but it's a big problem if documentation is. etc.
A "design doc", as described in the article, is a tool to help make a decision. It's a proposal. It is "ought". It describes the state of the world at a point in time, the desired change, and how to make it. Once the decision is made and the work is begun, it's rarely updated.
"Documentation" is just the state of the world (generally "now" or "at release x.y"). It describes the design and use of the system, but has very little digression into ways it could be different. If it links to a design doc, it should be for
Once you draw this distinction, it's clear that design docs should be in something like Google Docs, while documentation should be in something like a wiki or git. It's clear why it's fine for a design doc to be out of date, but it's a big problem if documentation is. etc.