Accreditation in software engineering

The Wall Street Journal has an article up on licensing. They make a claim that looks correct to me:

"Occupations prefer to be licensed because they can restrict competition and obtain higher wages," said Morris Kleiner, a labor professor at the University of Minnesota. "If you go to any statehouse, you'll see a line of occupations out the door wanting to be licensed."

The article covers a lot of the common issues, including mention of some of the more ridiculous license regimes such as for barbers and manicurists.

In software engineering, accreditation is much less prevalent than in other professions. The places I am aware of accreditation cropping up are for the more pigeon-hole parts of the craft, jobs where there's a well-defined set of tasks and a well-defined skill set for meeting those tasks. Examples are maintenance of Oracle databases or of Microsoft Exchange servers. Even in these cases, there is nothing illegal about performing the task without a license, and I'd hazard that more such systems are run without than with a formally certified technician.

The majority of software engineers I've encountered have no such license or certification at all. They are more jacks of all trades. They have all worked in some specialty or another at some point or another, but they've rarely completed an entire certification course. When hiring such an engineer, it's relatively complicated to evaluate them compared to licensed professions, but if you choose well, you typically get an enormously more productive worker than simply grabbing someone who has jumped through the right hoops.

All of this seems pretty good to me. Thus, unlike workers in most professions, I would argue against any formal licensing for software engineers. There are three big reasons:

• The track record of attempts is not good. Some large-scale efforts, such as those with UML-based death by paperwork, have been real productivity sinks for anyone who tried them. Other large-scale efforts, such as extreme programming, are so loose and hazy they are more rules of thumb than anything that could be taught and tested in a certification program. The best I've seen have been local customs adopted by individual development groups, but I've even seen a lot of these work out pretty miserably in practice and be retracted after a year or two.
  
  
• The profession is very young, and its practices are still being developed. For example, distributed version control has gone from theoretical to the norm in the last ten years. Garbage collection has gone from theoretical to the norm in the last thirty years. Even if we found some genius of software engineering who could describe today's best practices, it would quickly go out of date.
  
  
• The nature of the profession is to innovate. Unlike with plumbing or with shaving whiskers, a large proportion of new software written is something that's never been done before. It's wrong to think of most software as building a cog to fit into a well-specified gear in a well-specified machine. It's better to think of it like a business plan or a social arrangement or a new kind of tool. What kind of accreditation would make sense for the creators of Google, Facebook, or the Phillips screwdriver?