“...But by the time you achieve understanding, naturally the necessary insights (those required to cross the gap from a starting point of not understanding) feel obvious, unnecessary to mention, positively insulting to the future reader's intelligence by their simplicity...”
Incorrect appreciation. When I achieved understanding, the insights felt far from obvious up to the point it was necessary to include a warning.
Take into account that that was only an illustrative example of the psychological effect of expecting an immediate understanding but instead finding something very hard to understand.
Thanks for your point of view.
Thanks a lot. Interesting essay and interesting concepts.
I agree with you. I have seen several times how underbudgeted software projects sacrifice general quality due to the reasons you point, and this is later paid in the maintenance phase. I also think that an extreme domain complexity is not the most common cause of the problems.
Another source of maintenance difficulties is the laziness when writing the software documentation. A hard-to-read code can be a good code but very difficult to understand by other person when adequate explanations are unavailable.
It is easy to find articles and decalogues where experienced software developers manifest what they think are good rules for coding. Usually those recommendations are expressed with strong belief due to the reinforcement from similar opinions of most other authors, and due to they apparently emerge from plausible goals like readability, maintainability or simplicity. Who could question those goals? Probably no one since they are desirable goals but…are they objectively measurable?
After years of trying to think like a machine, what surely has affected my perception of complexity, I can write this response to some... (read 1199 more words →)
Yes, we could say that.