In Big Macs vs. The Naked Chef, Joel derides the least common denominator effect of formal methodologies:
Mystery: why is it that some of the biggest IT consulting companies in the world do the worst work?
- Some things need talent to do really well.
- It's hard to scale talent.
- One way people try to scale talent is by having the talent create rules for the untalented to follow.
- The quality of the resulting product is very low.
You can see the exact same story playing out in IT consulting. How many times have you heard this story?
Mike was unhappy. He had hired a huge company of IT consultants to build The System. The IT consultants he hired were incompetents who kept talking about "The Methodology" and who spent millions of dollars and had failed to produce a single thing.
Luckily, Mike found a youthful programmer who was really smart and talented. The youthful programmer built his whole system in one day for $20 and pizza. Mike was overjoyed. He recommended the youthful programmer to all his friends.
Youthful Programmer starts raking in the money. Soon, he has more work than he can handle, so he hires a bunch of people to help him. The good people want too many stock options, so he decides to hire even younger programmers right out of college and "train them" with a 6 week course.
The trouble is that the "training" doesn't really produce consistent results, so Youthful Programmer starts creating rules and procedures that are meant to make more consistent results. Over the years, the rule book grows and grows. Soon it's a six-volume manual called The Methodology.
After a few dozen years, Youthful Programmer is now a Huge Incompetent IT Consultant with a capital-M-methodology and a lot of people who blindly obey the Methodology, even when it doesn't seem to be working, because they have no bloody idea whatsoever what else to do, and they're not really talented programmers – they're just well-meaning Poli Sci majors who attended the six-week course.
And Newly Huge Incompetent IT Consultant starts messing up. Their customers are unhappy. And another upstart talented programmer comes and takes away all their business, and the cycle begins anew.
What's the moral of the story? Beware of Methodologies. They are a great way to bring everyone up to a dismal, but passable, level of performance, but at the same time, [Methodologies] are aggravating to more talented people who chafe at the restrictions that are placed on them. It's pretty obvious to me that a talented chef is not going to be happy making burgers at McDonald's, precisely because of McDonald's rules. So why do IT consultants brag so much about their methodologies?
Joel's entry, written in January 2001, is essentially championing the same Dreyfus Model of Skill Acquisition that the Pragmatic Progammers began advocating in 2002 with Herding Racehorses and Racing Sheep. Andy briefly covered this in the presentation he gave to our group, but the full slide deck goes into much more detail:
Level 1: Beginner
- Little or no previous experience
- Doesn't want to learn: wants to accomplish a goal
- No discretionary judgement
- Rigid adherence to rules
Level 2: Advanced Beginner
- Starts trying tasks on their own
- Has difficulty troubleshooting
- Wants information fast
- Can place some advice in context required
- Uses guidelines, but without holisitic understanding
Level 3: Competent
- Develops conceptual models
- Troubleshoots on their own
- Seeks out expert advice
- Sees actions at least partially in terms of long-term plans and goals
Level 4: Proficient
- Guided by maxims applied to the current situation
- Sees situations holistically
- Will self-correct based on previous performance
- Learns from the experience of others
- Frustrated by oversimplified information
Level 5: Expert
- No longer relies on rules, guidelines, or maxims
- Works primarily from intuition
- Analytic approaches only used in novel situations or when problems occur
- When forced to follow set rules, performance is degraded
As Joel points out, the value of big-Em methodology decreases very sharply as you climb the skill ladder. He's also saying that the resulting value of hundreds of level 1 and 2 coders banging out millions of lines of code is surprisingly low, but that's a topic for another blog entry.
The Dreyfus model is a general model of skill acquisition that was originally developed through observation of thousands of nurses performing their work. It has nothing to do with software development, per se. You could be a level 1 skydiver and a level 3 cook. But there are some interesting historical parallels with software development:
The nursing profession had a lot of problems in the 70's. The Benner book, and the Dreyfus model, is often quoted as being instrumental in helping turn it around. And if you read the book, you'll see that the problems faced by nursing back then have strong parallels to those faced by the software industry today.
And as Dave points out, you really don't want to be in a position where you're following a set of static, defined rules:
What can companies effectively outsource? Stuff that can be specified precisely. Stuff that has rules. This means that (in general) the jobs of novices will be more at risk from outsourcing that those of experts. Now, this is my no means a perfect model: companies outsource projects that shouldn't be outsourced, and companies have a strange habit of firing their experienced people in bad times because their salaries are 50% higher than the novices (why does no one ever account for the cost of all that experience walking out the door?). But, ignoring all the exceptions, in general we need to move away from the low Dreyfus levels and start occupying the higher Dreyfus levels if we are to to make ourselves less vulnerable to job evaporation. And Dreyfus is all about the acquisition of skills through experience.
Now, as amusing as it may be, I am not trying to encourage the level 5 means never having to say you're sorry attitude. "No rules" isn't shorthand for an air of smug superiority, although there's certainly no shortage of that in our profession. "No rules" means that we should actively seek out challenging development opportunities with lots of unknowns, work that takes considerable experience and skill. The kind of work that cannot be done by beginners slavishly following a big-Em methodology.