Course name: Managing Operations
A BRIEF DISCUSSION ON LEARNING CURVE
In General, Learning Curve Theory or Experience Curve Theory is defined as the following:
A learning curve is a graphical representation of the changing rate of learning (in the average person) for a given activity or tool. Typically, the increase in retention of information is sharpest after the initial attempts, and then gradually evens out, meaning that less and less new information is retained after each repetition.
The learning curve can also represent at a glance the initial difficulty of learning something and, to an extent, how much there is to learn after initial ...view middle of the document...
For example, if the hours between doubled quantities are reduced by 20% (rate of learning), it would be described as a curve with an 80% slope. Similarly 60%, 70% curves can be defined. Below is a picture of what the 80% curve might look like:
In other words, over time, it will take less and less effort and time to produce the same amount of output.
The concept of the learning curve is a powerful one and is applicable to all learning processes. It’s easy to see how to apply The Learning Curve to areas such as manufacturing where your outputs are physical products. It’s more difficult to apply The Learning Curve, however, in areas such as services or software.
For services, the easiest way to apply it is to measure the time it takes for someone to do something. Over time — the theory goes — that it should take less and less time for a thing to be accomplished.
For software, it’s difficult to apply the learning curve. It’s not good, nor is it prudent to argue that “over time, an engineer should be able to produce more and more code.” That statement reminds me of my former professor who created an entire neural net that was effective in predicting word-sense and he did it in just 2,000 lines of code. Something like that would have taken me 3x more lines of code. So, the statement doesn’t apply.
For example, there is learning about the domain in which a piece of software runs or is to run, and the specific needs that define the scope and purpose of the software and any changes to it. This responsibility is not only restricted to someone with the title “analyst”; it applies to all those who are involved in formulating the software, including the party for whom the software is intended. A common criticism of software customers is that they do not know what they want even though they know they want it; it is easier to reason about this perception from the perspective of learning. Unless there is a process that encourages learning on all sides, how else is the knowledge going to emerge clearly? Miracles and master plans? Feedback obviously plays a significant role in all this, and shortening long feedback loops is one of the optimisations that can make any approach more effective.
Henney is especially a big proponent of the concepts of “feed-forward” and “feedback”:
Design is both a feedforward and a feedback process, which makes it a dialogue: between people; between people and the design; between people and the results of the design. This is where learning fits in. So there is a need to shorten long feedback loops, but there is also a need to increase signal to noise ratio by reducing interference – continuous unregulated feedback is noisy rather than helpful.
So, in software, Learning takes place not just for the language used, but for the entire development process and lifecycle — including learning that occurs at feed-forward and feedback loops. The goal is to make these loops less noisy.
Impediments to Learning