Dave Thomas gave a talk at QCON London 2007 on how teams can write software better. He starts out by saying that picking a new tool or methodology will not help unless we address the root of the problem. That is, software is not written by tools, frameworks, methodology, or languages. It is written by people. In the 70s, there were 5.5 bugs per 1000 lines of code. In the 90s there were 5.6 bugs per. Even though languages changed (from cobol to c++), methodologies changed (from adhoc to PMBOK), and tools changed (from punch cards, to IDEs), there was no improvements in the number of bugs. So to make the software better, we need to make the people better.
Next, Dave looks at how to make the team better and improve their performance. Dave mentions that teams consist of members with different backgrounds and expertise, yet we like to treat them all the same. They all follow the same procedures even though they work differently and have totally set of needs.
Dave then explains the Dreyfus model for skill acquisition and its stages. The model suggest that most people start out as a novice needing rules and procedures until they gain experience and then work of intuition. Intuition is knowing something without knowing how you know it. Things just pop into your head and you have no idea where they came from. The model defines 5 stages:
1. Novice: You are doing something for the 1st time. You have no idea what you are doing. No interested in learning. You want detail instructions on how to solve the problem and get the job done. You are vulnerable to confusion and don’t know how to respond to mistakes. Novices require short term goals. As you do something over and over again you assimilate it (kind of like driving). It become below the level of consciousness and you get to become an advanced beginner.
2. Advanced beginner: you start trying things on your own, but still need to be told what to do. You have difficulty troubleshooting. You want information fast. You can place some advice in context. You begin formulating some principles but without holistic understanding. You are too busy concentrating on what they are doing. They cannot step back. Things that can help are pairing programming and unit testing.
3. Competent: You have big picture. You can do things for yourself. You seek out expert user advice. You are conscious and look for long terms plans and goals. You can troubleshoot on your own.
4. Proficient: You realize that there is a bigger domain. You are frustrated by oversimplified information. You will self correct previous poor task performance. You will learn from experiences of others. (It is like 3 year old always asking why?)
5. Expert: You are a primary source of knowledge and information. You continually look for better methods. You work primarily from intuition not reason. Forcing to follow set rules degrades performance. You require autonomy. You require the big picture.
Novices need context free rules. They need to see results quickly (about 30 minutes). Experts need to move beyond rules. We cannot treat people uniformly. We need to find out what their needs are.
Dave share statistics that show that the vast majority of people are at level 2. Dave suggests the reason for this is that a level 3 person is out on their own. They are making their own decisions. They are taking risk. At level 2, people need someone to help them every now and then. They do not take risks. They are safe and have a job to come into in the morning and leave in the afternoon. Also, from a company perspective, a group of level 2s wants to be told what to do, where as a group of level 3s or higher want to argue with you.
Dave suggests that when having a discussion, figure out the person’s level and communicate with them based on it. Consider what you need. Consider what the other party needs. Dave also suggests encourage competence by reexaming training and keeping the experts in practice by fixing pay-scales. In terms of personal growth, Level1 and level2 are the jobs that are vulnerable to outsourcing. So you need to move up.
Dave wraps up by explaining a technique how one improves. The way to do it is not through certification or years or work. These are just knowledge or just work and it is not experience. Experience doesn’t come from knowledge, it comes from practice. You need to build an experience portfolio just like a financial portfolio: Have a plan, diversify (languages, techniques, non-technical), look for value not just fads, be active (periodically review what you are doing), and just do it. It is not your company’s job to train you. It is yours. Invest a minimum 2 hours a week. There are no metrics for this. You’ll know it’s working when you get there.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Developing-Expertise-Dave-Thomas
