Learning Curve Risk
Part Of
Reduced By Practices
- Demo: Prototypes are a way of learning about a particular solution to a problem.
- Documentation: Detailed documentation helps manage and understand complex systems.
- Pair Programming: Facilitates knowledge sharing and learning.
- Training: Provides necessary education to help team members get up to speed.
If the messages we are receiving force us to update our Internal Model too much, we can suffer from the problem of "too steep a Learning Curve" or "Information Overload", where the messages force us to adapt our Internal Model too quickly for our brains to keep up.
Commonly, the easiest option is just to ignore the information channel completely in these cases.
Reading Code
It has often been said that code is harder to read than to write:
"If you ask a software developer what they spend their time doing, they'll tell you that they spend most of their time writing code. However, if you actually observe what software developers spend their time doing, you'll find that they spend most of their time trying to understand code. " - When Understanding Means Rewriting, Coding Horror
By now it should be clear that it's going to be both quite hard to read and write: the protocol of code is actually designed for the purpose of machines communicating, not primarily for people to understand. Making code human-readable is a secondary concern to making it machine-readable.
But now we should be able to see the reason why it's harder to read than write too:
- When reading code, you are having to shift your Internal Model to wherever the code is, accepting decisions that you might not agree with and accepting counter-intuitive logical leaps. i.e. Learning Curve Risk. (cf. Principle of Least Surprise)
- There is no Feedback Loop between your Internal Model and the Reality of the code, opening you up to misinterpretation. When you write code, your compiler and tests give you this.
- While reading code takes less time than writing it, this also means the Learning Curve is steeper.