Massive Learning Patterns

A recent research on learning patterns on humans and primates lead to interesting results: findings were that while young primates basically emulate the parent’s behaviour, human babies tend instead to imitate parents behaviour uncritically. Put in another way, they simply do what they see a parent is doing. One example was that if the mother was switching the light off with the forehead, babies were basically doing the same things, while young primates were acting in a more conscious way.

It might look like primates are smarter, but the evolutionary answer was the opposite: imitation is the fastest way to learn a series of complex behaviours in a short time, especially if you’re still too young to understand the reasons. Incidentally, learning by imitation, without asking questions is the same learning pattern adopted by armies all over the world, and they share the same goal: a lot of coordinated behaviours to be learned in a short time.

From primates to developers
Recently, we shifted some developers from Struts to Java Server Faces in the presentation layer of a couple of projects. Newer RAD-oriented IDEs (such as Java Studio Creator and JDeveloper) should have had a positive impact on productivity, after the initial phase. Still some of the developers claimed to be stuck in the learning phase, while others who just skipped the “I-have-to-learn-the-framework” phase and went straight to the code, copying some code snippets and adapting them to the project needs, performed significantly better both in short and long term.

Mere imitation, or code pasting, isn’t the whole story: babies imitate parents who have god-like authority on them, so their behaviour is accepted by trust before it can be understood. Similarly developers look for trusted sources of information to extract some proven solution (and the ability to dig the net for it is becoming a distinguishing factor among developers). In a closed context the perfect solution should be a robust prototype, providing a vertical example of a functionality.

As I experienced while coordinating offshore teams, a good prototype or an architectural skeleton removes whole families of problems, simply by providing a source for cut & paste: “if it comes from the architect it can’t be wrong”. Well… it obviously can be. But even a wrong repeated pattern is better than 20 differently wrong patterns spread all through the application.

Tags: Agile, Project Management