![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rNext two texts were intended for children. They describe obvious things. At least they are obvious for me. It seems many experts in information technologies understand these things differently or have not tried to consider problems from this point of view.
"Adult version" does not contain illustrations and samples. I also do not describe exceptions because they are not important. I write only a short version. Full detailed explanations are time consuming.
Note, if you feel something in the following texts is wrong, it is most probably your interpretation.
We do not solve problems in a direct way. We use mental models.
These models may be absolutely different.
"This equation system represents a parabola and a straight line. They have two intersections somewhere here and here."
"These damn formulas are like something I had seen in that book. I try to subtract this bottom line from this top line. Maybe I get some numbers at the end."
Mental models are usually simplifications. However they may be more complex than the objects they represent. For instance we must apply nontrivial visual constructions to understand operations with mathematical dots and straight lines.
The first and most important problem follows from the wording: these models are mental. This means they are something virtual within a person's head. In many cases the manipulations with these models are performed behind the border of awareness.
There are numerous consequences:
- We see solutions but the ways these solutions were found are lost.
- Mental models are inconsistent and incomplete. Sometimes they are strong structures within the range of human's ability. Sometimes they are random sets of illusions. In any case there are gray areas.
- It is impossible to transfer mental models directly. A model owner converts them into some transferable information and this information must be read by another person. Both processes are error prone. In many cases the information transmission channel introduces additional errors.
- To implement a solution a model owner must perform some operations that are derived from models but are not reversible. It is impossible to restore mental models from results.
It is simple to continue this list. Let's switch to the ways to reduce the damage in software development.
Any source code written in a conscious state is a result of some transformations originated in mental models of one or many persons. Even a simple copy-paste operation is performed for some reasons.
Usually the results are too far away from mental models to understand their connections. The obvious solution is to reduce the distance and to reduce the differences.
First way is to make the language a human speaks with a computer similar with the language a human uses for own conscious thoughts. This includes spoken languages, images and gestures from English words in Assembler till drawing with a stylus on a tablet.
Second way is the opposite direction: a human learns to construct mental models using specific rules. This includes a decomposition of a problem domain in classes, search of a mathematical solution and thinking in terms of Java keywords. (The last process is destructive when it is used for somethin other than educational tasks but a lot of programmers unconsciously apply it with disastrous results.)
Third way is to save models in some intermediate projection for documentation and communication purposes. These are names for variables, comments, UML diagrams, project documentation, sketches on napkins, etc.
Fourth way is to introduce rules that help to construct correct mental models, to make them consistent, to find errors and to simplify mental operations with them. Keywords are: mathematics, TRIZ, pattern languages, and some other unpopular terms.
Note, do not mistake the fourth way with terms constructed on base of words such as "think" or "decide". Most probably these are empty buzzwords like "design thinking", "system thinking", "intuitive decision making"...
Each way is uncomfortable and reduces performance. An attempt to think out something without concerning about rules and constraints is usually called "creativity".
Unfortunately it has two disadvantages: the results are unpredictable and almost always they are wrong.
Despite of this creativity is loved. It is enjoyable and productive. Rules and constraints may drive an expert team into a mental blind alley. A creative person without technical knowledge can always suggest a brilliant unrealistic solution.
On the other hand something uncomfortable and formal is not necessary correct and useful. Good intentions are only good intentions. Rules and constraints can not only prevent errors but also may cut out productive ideas and right solutions.
These four ways must be considered only as potential optimization possibilities.
The graphical diagrams we usually call "models" are only an attempt to go the second way and to store mental models as formal documents.
Usually this is made twice during a project: first version is made at the beginning to convince managers and maybe customers that programmers think before starting to write code, the second version emerges near the end as an attempt to convert "design" into something related to results of many coding - testing - patching cycles.
It is noting wrong with this method however there exist more useful ways for "modelling" with graphical diagrams.
The second widely known kind of "modelling" is the use of mathematical formulas.
The advantage of mathematics is the consistent formalized language and many established methods for error prevention.
The disadvantage of mathematics are inconsistencies on borders between the real world and mathematical abstractions. Mathematics is also inhuman and demands an appropriate education level and high mental abilities.
Formal mathematical methods help to find errors but the complexity of mathematics hinders to find mistakes in applications of inappropriate methods.
In many cases mathematics finds right solutions to wrong problems. Computers are also imperfect and introduce ugly rounding errors into ideal algorithms.
Now is the best time to proclaim The Dao of Four Ways but this is a boring idea. I simply end this text with a statement that there are many other methods to improve the link between mental models and source code. Each of them may be reasonable as long as the imperfect and mysterious human brain is included into the optimization formula.
"Adult version" does not contain illustrations and samples. I also do not describe exceptions because they are not important. I write only a short version. Full detailed explanations are time consuming.
Note, if you feel something in the following texts is wrong, it is most probably your interpretation.
Models
We do not solve problems in a direct way. We use mental models.
These models may be absolutely different.
"This equation system represents a parabola and a straight line. They have two intersections somewhere here and here."
"These damn formulas are like something I had seen in that book. I try to subtract this bottom line from this top line. Maybe I get some numbers at the end."
Mental models are usually simplifications. However they may be more complex than the objects they represent. For instance we must apply nontrivial visual constructions to understand operations with mathematical dots and straight lines.
The first and most important problem follows from the wording: these models are mental. This means they are something virtual within a person's head. In many cases the manipulations with these models are performed behind the border of awareness.
There are numerous consequences:
- We see solutions but the ways these solutions were found are lost.
- Mental models are inconsistent and incomplete. Sometimes they are strong structures within the range of human's ability. Sometimes they are random sets of illusions. In any case there are gray areas.
- It is impossible to transfer mental models directly. A model owner converts them into some transferable information and this information must be read by another person. Both processes are error prone. In many cases the information transmission channel introduces additional errors.
- To implement a solution a model owner must perform some operations that are derived from models but are not reversible. It is impossible to restore mental models from results.
It is simple to continue this list. Let's switch to the ways to reduce the damage in software development.
Any source code written in a conscious state is a result of some transformations originated in mental models of one or many persons. Even a simple copy-paste operation is performed for some reasons.
Usually the results are too far away from mental models to understand their connections. The obvious solution is to reduce the distance and to reduce the differences.
First way is to make the language a human speaks with a computer similar with the language a human uses for own conscious thoughts. This includes spoken languages, images and gestures from English words in Assembler till drawing with a stylus on a tablet.
Second way is the opposite direction: a human learns to construct mental models using specific rules. This includes a decomposition of a problem domain in classes, search of a mathematical solution and thinking in terms of Java keywords. (The last process is destructive when it is used for somethin other than educational tasks but a lot of programmers unconsciously apply it with disastrous results.)
Third way is to save models in some intermediate projection for documentation and communication purposes. These are names for variables, comments, UML diagrams, project documentation, sketches on napkins, etc.
Fourth way is to introduce rules that help to construct correct mental models, to make them consistent, to find errors and to simplify mental operations with them. Keywords are: mathematics, TRIZ, pattern languages, and some other unpopular terms.
Note, do not mistake the fourth way with terms constructed on base of words such as "think" or "decide". Most probably these are empty buzzwords like "design thinking", "system thinking", "intuitive decision making"...
Each way is uncomfortable and reduces performance. An attempt to think out something without concerning about rules and constraints is usually called "creativity".
Unfortunately it has two disadvantages: the results are unpredictable and almost always they are wrong.
Despite of this creativity is loved. It is enjoyable and productive. Rules and constraints may drive an expert team into a mental blind alley. A creative person without technical knowledge can always suggest a brilliant unrealistic solution.
On the other hand something uncomfortable and formal is not necessary correct and useful. Good intentions are only good intentions. Rules and constraints can not only prevent errors but also may cut out productive ideas and right solutions.
These four ways must be considered only as potential optimization possibilities.
The graphical diagrams we usually call "models" are only an attempt to go the second way and to store mental models as formal documents.
Usually this is made twice during a project: first version is made at the beginning to convince managers and maybe customers that programmers think before starting to write code, the second version emerges near the end as an attempt to convert "design" into something related to results of many coding - testing - patching cycles.
It is noting wrong with this method however there exist more useful ways for "modelling" with graphical diagrams.
The second widely known kind of "modelling" is the use of mathematical formulas.
The advantage of mathematics is the consistent formalized language and many established methods for error prevention.
The disadvantage of mathematics are inconsistencies on borders between the real world and mathematical abstractions. Mathematics is also inhuman and demands an appropriate education level and high mental abilities.
Formal mathematical methods help to find errors but the complexity of mathematics hinders to find mistakes in applications of inappropriate methods.
In many cases mathematics finds right solutions to wrong problems. Computers are also imperfect and introduce ugly rounding errors into ideal algorithms.
Now is the best time to proclaim The Dao of Four Ways but this is a boring idea. I simply end this text with a statement that there are many other methods to improve the link between mental models and source code. Each of them may be reasonable as long as the imperfect and mysterious human brain is included into the optimization formula.
no subject
Date: 2018-03-15 12:14 am (UTC)no subject
Date: 2018-03-15 06:23 am (UTC)no subject
Date: 2018-03-15 09:58 am (UTC)Скрижали Моисеевы?
no subject
Date: 2018-03-15 10:08 am (UTC)