Acquiring skills

According to the great book Thinking, Fast and Slow by Daniel Kahneman, that’s what humans need to acquire skills:

  1. An environment that is sufficiently regular to be predictable
  2. An opportunity to learn these regularities through prolonged practice
  3. To receive immediate and unambiguous feedback

The first bullet is of course an absolute prerequisite for developing skills, but I see a lot of young developers which would swear that the overly complicated frameworks they are dealing with behave irregular and non-deterministic. Too many layers of abstraction might be obstructive here. Maybe the not-invented-here anti-pattern directly results from the desire to have a regular and understandable environment.

In my experience, in software development the only level which is “sufficiently regular to be predictable” is the source code itself. And nothing else. That’s the reason why I prefer Open-Source projects and do not google for some helpful discussion threads, but directly debug into the framework code. That’s to only path to real understanding.

But of course, that’s very time consuming, which brings me to bullet number two from the list. It is perfectly clear, that gaining skills in a complicated environment such as JEE needs a lot of time and effort. And also curiosity and the will to understand. The question is, do we have to give the developers time and room for this within the project? Not explicitly, a software developer has of course the responsibility to read books and try things out in his or her spare time. But what we must do is to advice developers to understand before acting. To find the root cause for a problem instead just applying possible fixes found in the internet (without understanding them). The latter might be faster, but leads to very fragile software, hold together by chewing gum and prayers.

I find it astonishing how many developers cannot answer the question: “What was the problem?”. Maybe the second bullet should read as “An opportunity and the will to learn these regularities […]”.

Another good possibility to “learn the regularities” is building prototypes. Use small prototypes for evaluations whenever possible. Also late in the project. Don’t evaluate concepts by fiddling around with the actual project. It is difficult to learn at this level of abstraction and complexity.

One good thing in software development is, that we receive immediate feedback if it “works”. This criteria is also “unambiguous”, as demanded in bullet three above. However, it’s not that simple. For most code quality criterions it is rather difficult to get immediate feedback (or feedback at all). A working peace of code might be very difficult to read and to maintain for others. Or have a pretty bad performance. And these are things are not so unambiguous as they should be. There are a lot of different opinions out there how readable code should look like.

What can we do to get (and give) feedback for non-functional code quality criterions? First of all, developers should actively seek for feedback from other developers. The other developer should at least be equally experienced, if he/she is more experienced, even better. That’s the reason why each team needs at least one or two senior developers. Without them, a young team learns not much else than how to hack together something that just somehow works (for the moment). I’ve seen such code, a horrible waste of time and money.

Here my tips how to support skill acquiring:

  • Avoid overly complicated frameworks (not-invented-here might not always be that bad)
  • Use open source whenever possible and encourage developers to have a look at the source code and check out how things work
  • Demand a root cause analysis for all bugs and issues
  • Let the team build prototypes for all concepts that need to be evaluated
  • Back the team with at least one senior developer
  • Advice the developers to discuss how they plan to implement something with at least another (equally or higher experienced) developer
  • Do regular code reviews to provide feedback for non-functional quality criterions

Agile a good kept secret?

In his post Steve Denning suspects, that Agile Management is therefore a good kept secret among managers, because the wrong people invited it:

Unfortunately, these management discoveries were not made by “the right people”: academics in business schools or high-paid managers in big corporations. The discoveries were made by the people that, in prospect, you would think are the least likely people to have solved a management problem: geeks. Software developers were known to be antipathetic to both managers and management. Badly dressed, unkempt, even sometimes unwashed, speaking about issues that managers could hardly grasp, these employees were the most problematic of a big organization’s employees. How could they possibly have solved a problem that had stumped the finest management minds on the planet for decades?

And then he states, why only those people could have invited Agile principles:

The standard prescriptions of management didn’t work with software development. Something different had to be found.