Parsimony is also called ”Occam's razor”. It means that given two equally accurate answers, science prefers the simpler.
Einstein’s classic quote is a bit false as he was AGAINST simplifying to the point that laypersons might understand - if it were simple enough to understand, it wouldn’t be a discovery worth lauding!
The full quote is in fact:
It is sad that the use of ”make it simple” has been ”stupefied” to a degree where we can actually choose an apple instead of a full dinner plate, stating that it is simplification without reflecting on parsimony.
The second part of the famous quotes from both Einstein and DaVinci which is so often left out or ”forgotten”, means that we can not compare things regarding ”simplicity” if they do not have the same effect and context.
Remember: The complex does not disappear if we hug each other or hold hands in a ring.
So what does ”comprehensive documentation” really mean. If you do not understand that there are different TYPES of documentation with different needs depending on the situation and the involved stakeholders, then read the quote by William Blake: ”if you generalize, you are an idiot!”
We need to be able to predict which knowledge will be needed in the future. In those cases (and they are many!) verbal communication is not enough semantically powerful, and “only talk” often lead to inefficient, misleading communication and different interpretations where the “internal models” do not match at all ... But the participants are not even aware before it is too late, and bad decisions are already made.
We should definitely ask ourselves if a “living product/project backlog” is sufficient. For real!
Certain product- and project contexts demand certain information in a specific format for a set of identified regulators. Just to follow the law!
It means that the specific Knowledge Representations MUST be a part of the product, and without it, we will be breaking a set of laws and standards! In other words, we MUST create, read and update these documents to obtain legal approval for the product/project work we are doing.
We need to know which information that has a lasting value beyond the initial development effort.
In many cases, we gain time and are agile by keeping some sort of representation of discussions about decisions “outside the head”. If we do not all have the same idea on the goals that the system was built to achieve
or which use cases that are the most important for the automatic system and the manual process, then we will probably have some major problems in the future (or giving someone else an impossible task). We need to save decisions made during development on why we have included or excluded certain functionalities, constraints and why we have focused on certain quality attribute values and not cared about others. Or why we did not involve stakeholders from group X, but we spent a lot of time with stakeholders representing domain A and B...
To be agile is to be smart!...do not be agile stupid and “throw away” a “map” that can help you to understand and do your job faster and more effectively as well as enhance communication. To throw away important knowledge because some “manifesto guy tells you to simplify” is like not using a hammer while building with wood and nails. Just stupid.
If you need requirements and test cases for specific parts of the system, just represent that knowledge!
One size does NOT fit all, and direct verbal communication is NOT always the best!
We should also be open and agile for the fact that a lot of stakeholders prefer written documents, visual diagrams and info graphs, rather than just meetings, talk or reading the source code
We should never document for the sake of documenting, but IF communication documentation is successful then we should definitely archive the knowledge representation.
One of the most important uses of representation is to improve and support thinking & understanding. We want to represent knowledge (e.g. writing, drawing/modelling to enhance our thought processes and the “mental models” and to be able to do that not only individually but also collaborate on a “collective mental model”
The happy part is that improved thinking and understanding will last even if the knowledge representation created for the specific problem is “thrown away” and not stored or updated!
The process of “drawing the map” forces people to ask questions that enhance the understanding and often creates a new way of thinking! AND it is possible to SHARE!
And it has nothing to do with drawing funny cartoons on flip charts.