2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- March 18, 2010
- Rants
In feedback learning timing is everything. I’ve had the good fortune of working with dolphins in research projects a few times in my life. When we train dolphins to learn a new behavior we use a “bridge”, which is a high pitched whistle that we sound at the moment they do the behavior we want. Using this technique these animals learn exactly what we want of them very quickly.
The same is true with human learning. The farther the reward is from a behavior we’d like to learn, the more difficult it is to instill as a new behavior. This is called “delayed gratification” and many studies have been done on it. For example, in one research study the researcher offered cookies to small children. The researcher said, “You can have one cookie now or, if you wait until after lunch, I will give you two cookies.”
There were a lot of situations like this where the children had to delay their reward to receive a bigger reward. Researchers kept tabs on these children over the years and discovered that the ones who were willing to delay their gratification—to get two cookies after lunch instead of one cookie now—were invariably more successful in life, and not just financially; success was measured in terms of contribution, relationships, satisfaction, and many other criteria.
One aspect about writing software that we developers love is we get instant gratification. Often the time it takes from conceptualizing a solution to seeing it run on a computer can be a matter of hours or even minutes. This is very satisfying.
But some aspects of our software development efforts don’t show up until much later. For example, we can write small programs without the need for consistently held engineering practices and not have problems but when we attempt to build large enterprise systems without paying attention to critical practices we often end up with a mess that is very difficult to work with.
Previous Post: « Software is Too Forgiving
Next Post: The Limiting Factor »