Where did Joe the Plumber get that misinformation?

Back in late 90s I managed to get second best score in the country (for that year) in Visual Basic exam under Microsoft Certified Solution Developer program. The catch was that I had have never written a single line in Visual Basic nor had I have any substantial database development experience.

So, yeah, it is entirely possible to get certified and not know a thing about a certification subject. Guy's got a point.

I got my MCSA while in high school. When Microsoft offer the Dreamspark certifications, I jumped on the free upgrade test, and went and took it. I spent an hour or so studying for it, and got >900. Does that mean I am qualified to manage a Windows 2008 ___domain? Maybe. What it does mean, however, is that I am at least somewhat familiar with the tools that are available.

While this may not be the same situation for programming certifications, I know for a fact that the MSCx certs have been helpful. While I don't know the ins and outs of maintaining a server, I am consistently shocked when I talk to a "server guy" who doesn't understand Active Directory structure at all, or the various types of inheritance that go on in Windows. I may not know everything, but at least I know what I don't know.

That, I think, is the biggest benefit of a certification. It may not show what you do or do not know, but it does show that you at least know of the topics, which is more than can be said about many people.

Even in screening resumes it absolutely should not be your only deciding factor, but it is one good factor to look for when going through large stacks of resumes.

Programming has no barrier to entry. One of the only ways to see how well someone can write code is by actually looking at their code. There's no shortcut, for better or for worse.

With that said, most hiring managers are deluged the moment they announce a job opening. You cannot practically do a code review on every applicant. When staring at a stack of resumes you need to be able to tell who is worth the time to do an interview and possibly a code review on.

When I see a certification on a resume, it tells me a couple of things:

1. They studied at least enough to pass that test. As someone who has passed many of these tests, I am well aware that for most certifications this is a low bar indeed, but that is more than the nothing that many resumes have, especially for entry level positions.

2. They care enough to take the time to do this. I know they are doing it primarily to impress hiring managers, so again this is a low bar but it is more than nothing.

Especially when dealing with entry level candidates, it is a valuable data point in determining who gets an interview. I would never recommend making a hiring decision based on it, but, especially at the entry level, it is a good way to help pick out people for interviews and possible code reviews.

Here's a basic idea. It might be one of many:

Software x has been developed in the following way (explained here). Which of the following are not valid statements about x?

1) x is free of defects 2) We can have confidence that x will work under these circumstances <...> 3) ...

I mean, sure, you would need to contrive a proper example, but that is the kind of thing I am advocating. It should be a test that a competent developer who actually thinks about quality at all should be able to pass without much in the way of study or "extra work". People who do not think about the quality of the software they produce would need to learn about these issues.

We asked to implement a splay tree container in C. Got back clean and working code, followed up with phone interviews, then brought these guys in (from another city) only to discover they didn't know what the offsetof() was. Even though it was used in the code they have submitted.

Please explain?

The ancestor post by huhtenberg says he obtained certification for Visual Basic although he never wrote a single line of it before. My suggestion for the certification process is to actually use the skill at question, and using that as a basis for obtaining the paper that says "Yes, I can do this proficiently", where the skill in question is software development, not memorizing book knowledge. Why not test software development by making the test taker develop software?

That would be more valuable than being language certified.

As a thought exercise, imagine a job that requires a qualification that has little-to-nothing to do with the actual profession.

This would both artificially increase the barrier to entry for people with skills but no qualification, while decreasing the barrier to entry to those without skills who have passed the qualification.

Of course, that assumes that it is more difficult to become certified overseas, and I doubt that would ultimately be the case. It'd probably still be financially advantageous for outsourcing firms to invest in the means to certify offshore developers.

Joe the Developer doesn't need a certificate, but "we the people" (as in the people who have his software inflicted upon them) would rather he did.

The certification argument seems to forget whose benefits from certification. It's not the developer - it's the people who are able to ensure that there is a baseline level of competence among software developers entrusted with certain kinds of development work.

I'm all for certification.

These are very large projects, using hundreds of developers. The quality of the team members varies. Half are below average for the population at large.

Adding certification on top of this doesn't change the fact that half the developers will be below average. The projects are too large.

(Actually, if the rockstar programmer stories are true, then it's way more than half of the programmers that will be below average. Which strengthens your point in a way.)

There's a simple reason why - it costs x to certify 1 developer, and y to certify a piece of software.

For most software, "y" is still too expensive to offset the potential damage caused by software failure (compared to a jetliner, where the potential cost is huge).

A programmer may create hundreds or even thousands of pieces of software during a career. Average x over that number of projects, and it's negligible. Multiply that number by y, and you have an enormous figure.

Also, the cost of certifying a piece of software to provide any kind of assurances of quality is time consuming and expensive. Compare this to a certification that shows that anyone who wants to claim to be a "software engineer" actually knows the first thing about software engineering, and is at least capable of producing software in a systematic way.

It's just like we license drivers once and assume that that basic level of competency will ensure "quality driving" on a variety of road types. We don't certify each driver for each road individually.

You can guess one way -- as you clearly do -- and it looks like the up-front developer certification cost dwarfs the software certification cost when amortized over all projects. This might remain true even when multiple developers are considered.

You can also guess another way -- as I do -- and it looks like the up-front and recurring costs to properly certify a developer and maintain that certification would be very large. It could be so large that, even when amortized across many projects, it's still comparable to (or even more costly than) certifying the individual projects.

The process requirements on these projects (DO-178B) call for an organization to institute a systematic way of developing software across the project that everyone on the project follows. An additional certification for each individual is not necessary. Either they can follow the process or they are reassigned.

I am not. I'm talking about anything that people are expected to spend money on. The certification passes to the software, and then users are capable of making slightly more informed decisions.

I'm a formal methods geek, so I generally advocate theorem provers for stuff which is actually safety critical. To me, certification of developers would just be a way of lifting the general quality of the non-safety-critical stuff that still has the opportunity to cost people lots of time and money.

Think about viruses, for example. People complain about viruses causing millions of dollars of damage.

The virus didn't actually do any damage. The shonky programming that allowed the virus to propagate in the first place did.

And that's why certification is important. Hopefully it would at least ensure that people writing software are familiar with the issues that can affect software quality.

You're making one huge assumption here: that the certification actually certifies anything at all. As a matter of fact, it does not. Certifications are useless. Having or not having a certification is no indication of presence or lack of programming skill.

I'll go further, though. The certifications do you, as the public who makes use of developer services, a disservice. They imply that someone has verified and certified "a baseline level of competence" - but that implication is a fabrication, a lie.

All the certifications do, effectively, is give people who shouldn't be in programming jobs working for people who shouldn't be hiring programmers.

Bet you're not a fan of driver licensing either, right? 'cause a driver license is no indication of the presence or absence of driving skill, either.

Oh, wait, yes it is.

I think one huge problem with software engineering is that hardly anyone within the industry can even agree about what the "gold standard" should be. In those circumstances, it's extremely hard to figure out what a "proper" certification should entail. Even decent certifications end up being opinionated pieces of paper that don't really mean anything to most of the industry.

Fundamentally, programming is about problem-solving. Beyond an IQ test, I'm not sure how you can certify that effectively.

You're talking about programming - I'm talking about certification of software engineering. They are two separate-but-related concepts.

A certification should not be "Joe knows the syntax of language X according to some test" - it should be "Joe is familiar with this range of techniques that can be applied to produce higher-quality software". These are reasonably easy things to test, and their presence or absence is not related to intelligence or programming skill.

Whether (as employees) these programmers actually are expected to apply these concepts is irrelevant. The fact that everyone knows what everyone else knows leads to a basic assumption that you either are applying some good software engineering techniques, or you have examined the reasons why you are choosing not to apply them.

The problem is that we have developers who are perfectly capable of writing good quality software according to some development practice, and developers who don't even know these things exist. If everyone knows what everyone else knows (and users know what developers are expected to know), then we start getting some pretty good assurances that people have at least considered these issues.

And that's worthwhile.

That's a very strong claim, unless your bar of quality is set very high.

Requiring certification would, it seems to me, make it more difficult to determine which developers to trust. Just because Joe has a piece of paper saying that he knows X, Y, and Z doesn't mean that Joe isn't going to take shortcuts that end up costing the company thousands or millions of dollars (or human lives!). Because Joe has this piece of paper, companies may be lulled into thinking that they don't need to test him as hard or give him as long a trial period before entrusting him with critical systems.

Any certification process that simply involved rote learning or which could be googled wouldn't be worth the paper it is written on. I'm certainly not advocating that.

> Just because Joe has a piece of paper saying that he knows X, Y, and Z doesn't mean that Joe isn't going to take shortcuts that end up costing the company thousands or millions of dollars (or human lives!).

Sure, certification doesn't do away with the need for QA and internal processes. It just ensures that anyone producing software that targets certain markets will have a basic understanding of which corners they are cutting. The government, for example, could mandate that they will prefer suppliers who have a certain percentage of certified developers. Playing an averages game, that at least means that somebody in the company is going to know when corners are being cut, rather than just having a group of people hacking along.

> Because Joe has this piece of paper, companies may be lulled into thinking that they don't need to test him as hard or give him as long a trial period before entrusting him with critical systems.

As I said before, the assurances provided by certification are not for the benefit of employers, they are for the benefit of users. If your hypothetical company actually did this, then they would be a very dumb company.

> Playing an averages game, that at least means that somebody in the company is going to know when corners are being cut, rather than just having a group of people hacking along.

My argument is that this is completely false. In fact, I suspect that there would either be zero correlation between cluefulnes and certification or actually a negative correlation. The reason for this suspicion is both from looking at certifications required for other disciplines and looking at the best developers I know, all of whom have little to no use for certifications and are too busy doing awesome stuff to bother with formality and process (yet whose code consistently has the fewest and least severe bugs and is the most unit-tested of any code in the repository).

There's certainly no question that a certification process could weed out maybe the bottom 5-10% of all developers if all professional software developers were required to take it. But the nature of software development is such that these developers are not the ones in danger of causing the collapse of civilization anyway. I would guess, and this is just my guess, that it's the ones who are in the top 50% but not in the top 10% who tend to wreak the most havoc: they have shown enough skill to be given important tasks, but due to time constraints or inexperience or whatever they make mistakes or cut corners.

Thus, if I were a client, I would be more interested in choosing a company or supplier that has a policy where any code checked in must be reviewed by at least one experienced developer. I'd be interested in making sure that they write repeatable automated tests and use code coverage tools to ensure that their tests are testing what they think they're testing. I'd be interested in making sure that they had a mentoring program that allows new hires to be taught by experienced developers. Any one of these things would put my mind at ease more than any certification process.

That's what tests are for.

gdp is right: certifications are useful if they are rigorous, targeted and demand useful knowledge and training

I doubt most developers would say that licensing pilots or physicians is useless but that's essentially the same thing as claiming that certifying programmers is useless.

Engineers are probably a better comparison: while engineers do have expensive certifications, they aren't the ones doing most of the engineering. Instead, they're the ones verifying that the engineering (done mostly by non-certified engineers) meets the design requirements.

As far as your comment about engineers being a better comparison and axod's comment that "most software is fun..." (WTF!!! do you think businesses expend millions of dollars yearly on IT so they can have "fun?"), I call bullshit! As someone with experience and in both hardware and software engineering, I can assure you that most engineering is verified by non-certified (I assume you mean PE's) engineers.

I live daily with software that has to work. Serious bugs are not tolerated in medical devices. The attitude that "oh, we can fix that in the next release, just tell the operator not to hit F8 before F7 or they'll misdiagnose the patient" simply doesn't fly around here.

Sorry for the rant, but attitudes like this are exactly why software development isn't taken seriously by most professions!

Now, what I mean by "certified" varies a bit across disciplines. The professional engineer cert is a general certification, which is generally much less useful than specific certifications for particular disciplines. The considerations in electrical engineering are considerably different from those in, say, structural engineering. While there is also significant overlap, you're not going to get a general-purpose "engineer" who can verify both.

Would it be ten? Thousand? Your yearly salary?

Most software is just fun stuff that makes peoples lives slightly better. Only a small amount of software is 'mission critical'.

If software breaks, it usually doesn't cause the loss of life.

Certification would ensure that Joe is capable of writing tests that actually test anything, for example.

We generally hope that a degree would give you a baseline level of competence, but I'm not sure that is entirely true either.

Not all degrees programmes include even the first thing about software engineering - they have plenty of programming, but nothing that would actually ensure that people have a systematic approach to software development.

When a senior dev rants about how they don't need a certificate, I agree, but counter them with the question: If certificates are so easy to get and meaningless, why haven't you bothered to get them?

Note: I can think of a number of reasonable answers why not... but their response to that question is often enlightening as to exactly what kind of dev they are.

To a big corp, it signals that you play by the rules, and that a 3rd party has vouched for you.

To a small company, it signals that you don't learn by yourself, and expect things spoonfed.

I'm not saying either is wrong, but they are different mindsets, large companies have more need to order than small companies.

I don't think they say that at all. Now, I do get that impression about some people that list tons of training classes on their resume (especially the ones that list training classes without an accompanying certification).

Personally, I hold an MCBDA, MCITP, and A+ certifications. I pepared for the MCDBA and MCITP on my own through a combination of books, websites, and hands on toying with the systems. I prepared for the A+ in a peer group. I have had a mentor that taught me a tremendous amount, but I never took formal classes for any of it, or expected any of it to be spoonfed.

Aren't you answering your own question here?

The biggest problem is cert's would almost never pass the same standards as the equivalent from most govt's Education Exam board. If they did, perhaps they would be more useful. Education Exam standards can also vary significantly between countries, and these com's sadly can't be bothered in expending the effort internationally.

Unfortunately some of the certified people I've met have been so genuinely awful that I don't think you can even claim that. I tend to be with the article author on this one - people tend to get certified because they are unable to compete in other ways and want to bolster their resume.

Could someone please explain to me why a market-based meritocracy for programmers isn't good enough? The good programmers either establish a reputation and references by doing quality work for other companies, or they can provide examples of code they wrote independently.

I think that the lack of mandatory certification is one thing that has allowed software to become such a vibrant field. It's as much an artistic or creative profession as an engineering profession. For the jobs that require engineering precision, a developer's work (or an artist-for-hire's portfolio) should be sufficient qualification.

That and also that several people (and I don't want to generalize because they aren't all like that) I have met with such certifications have belief that there is a "one true way" or recipe of doing things and are uneasy to adapt or step out of this course. Maybe it creates in these people the false conviction that there is an infallible answer to all problems.

I was sitting there one night thinking 'I know that guy.' And I did. He looks good on tv too. Lost some weight, big smile, nice clothes, smooth delivery -- same as when he used to say, "I not really sure, let me call Colorado and escalate this."

Active developer with daily practice does not required any certifying papers. Good developer even didn't hide his code. Piles of high quality code. Look at the people who bring us linux, freebsd, openbsd and thousand other projects.