[refactored from TheJobMarketSucks]
One could probably write entire books about the MicrosoftTestingScam?. It used to be only hardware and software went obsolete, but with Microsoft's constantly-changing requirements, so does your certification.
Given that a person gets certified on a particular set of technology, it's only natural that the certification gets obsoleted when the technology does. If you can get a job working on the obsolete technology, your certification will mean as much as it always did (i.e. not much).
This is common, and not just in the IT field. Look at surgeons... a surgeon has to be certified in each and every type of operation they do, and new operation procedures are constantly coming out that take advantage of new technology. Pilots can lose ratings if they don't log enough hours in a particular plane type. Accountants have to renew their CPA license every year. Heck, you have to renew your driver's license periodically, and there are places which make you take the driving test again when you do so.
As the software industry becomes more professionalized, you can expect to see a minimum level of certification become required (and the certification will actually mean something, too!). Odds are that the certification will have an expiry date, and it won't be cheap to get either. That's just the way things are headed. -- RobertWatkins
[ThreadMode starts here]
Bad pilot -> multiple deaths Bad surgeon -> death and worse Bad accountant -> IRS audit Bad software developer -> tossed out w/his bad code after first code reviewDo we really need certification in our industry? -- SteveHowell
The last example assumes that there is a "good" software developer around who can examine the code. What happens if there isn't? You get bad software developers -> bad software -> anything, where anything could easily be a business going down the tubes 'cause their custom inventory control software sucked. In any case, the presence of a good certification will mean that the number of people you have to toss after their first code review would be a lot less. Please note that I don't think there are many (if any) good certifications around at the moment.
Stealing a page from SteveMcConnell's AfterTheGoldRush, you wouldn't necessarily have to certify every developer in an organization. It would be sufficient to certify only a few, and require that projects have at least X certified programmers working on them. These certified programmers would be liable in the event of disastrous malfunction, and they would therefore be rather stupid to work in an environment which they feel would not produce quality code. This is how civil engineering certification works, for example.
Personally, I think we do need some standard level of certification in our industry desperately. The standard should be graded, come in multiple language flavours, be peer-reviewed by a major programmer association like the ACM, and be reasonably cheap. A minimal level would say you understand basic programming concepts and syntax in one language, which means you could probably work if someone holds your hand.
I think the state of Texas is moving towards this model. -- RobertWatkins.
There are two plausible reasons to certify programmers:
1) Certify programmers so software houses don't hire bad programmers.
2) Certify software houses so that businesses don't hire bad software houses.
Correlations: 1) There is no excuse for software houses to hire bad programmers. If a software company can't identify bad programmers, then it has no business being in the business of producing software.
2) There is no excuse for businesses to hire bad software houses. If a business does not know enough about software to evaluate the quality of solutions that a software house brings to its customers' business problems, then the company is probably better off solving its business problems without software.
Of course, I'm not naive. Companies hire bad programmers and bad software houses all the time. But, ignorance is a fact of life, and creating an expensive software certification industry creates only an illusion of safety. Software certification is good for lawyers and test administration companies, but it's bad for software developers.
-- SteveHowell
In response to the correlations:
1) I'd generally agree with that. However, said identification is expensive, and mistakes are time consuming. A graded level of certification would help reduce costs here. However, please note that not all programmers are employed (or should be employed) by software houses. Lots and lots of in-house programmers and private contractors out there.
2) A business should know if a proposed solution addresses their problems. However, most businesses aren't in a position to evaluate if their software is robust, or if it's likely to fall over come some magic date (to name one example). If I hire a construction company to build a skyscraper, do I have to check to see if it will fall down in a stiff breeze? No, it's the company's problem to verify this, and I would take them at their word.
The thing about certification is that it gives you someone to blame. Engineers started being certified in the US when bridges and buildings started falling down on a regular basis. Once that started, certified civil engineers became liable if they signed off an construction project that later failed catastrophically. Was this bad for the civil engineers? Oh you bet. Was this bad for society. Hell no.
Certifications are a filtering process. By themselves, they don't help much. Combine with liability (and I am a professional software developer advocating this, btw), and you get a much more reliable process. Half the problem with the IT world at the moment is that it's too easy to shrug and say "we stuffed up, and it'll cost you this much to get us to 'fix' it".
Having such a certification level in place wouldn't rule out uncertified developers, mind you. Taking the construction industry as an example again, there would only probably only be on certified engineer on the site. He might have a couple of engineers working under him, with proper degrees and all, but no certification (or a lesser one). The engineers supervise the construction workers, who may or may not be certified. The worker's certification will probably be in the form of a union ticket, or maybe a license to operate a certain piece of machinery, like a crane or forklift.
Now, all this paperwork doesn't mean you need to be a certified builder or engineer to put up a garden shed. Heck, it doesn't even mean you can't get paid for putting up a garden shed. But without this certification, you can't build a large building. And this is a GoodThing, IMHO. The same analogy goes for software, even software that doesn't kill people when it fails. -- RobertWatkins.
This discussion has focused on the benefits of certification, but not how certification is possible. There's no generally agreed-upon standard in the industry, that I'm aware of, about what "good code" is. Some people think comments are important; others think comments are a sign of trouble. Some think up-front design documentation is important; others don't. Some like UML; others like ad-hoc whiteboard scribbles. I've even seen disagreements about whether it's better to have one long method or lots of short, small ones.
Software certification concerns me because I don't think our industry is mature enough to say what the best practices really are. If we have a standardized certification test, programmers will be taught to that test, and alternative approaches to developing software would be even harder to introduce than they are today.
-- JimLittle
Likewise, I'm not sure that the industry is at a stage where we can really say what a good certification process would look like. However, from looking at engineering ones, I think we can expect the following:
You can easily certify drivers (forklift, truck, whatever), because bad drivers do objectively bad things like failing to use their turn signal or knocking over orange cones. The certification process, though, is secondary to driving record for all but new drivers.
You need to give us concrete examples of objectively bad things that software developers do that certifications could spot.
I disagree with you that certificates for low-level software skills have any value. What are you going to do, hire the junior programmer to run your editor for you? Hire the junior programmer to hit the compile button?
I do agree with you that higher-level certificates will be difficult to concoct.
I believe you when you say that you're not sure how good certification could be achieved.
-- SteveHowell
Accountability vs. Certification
The thing about certification is that it gives you someone to blame. Engineers started being certified in the US when bridges and buildings started falling down on a regular basis. Once that started, certified civil engineers became liable if they signed off an construction project that later failed catastrophically. Was this bad for the civil engineers? Oh you bet. Was this bad for society. Hell no. -- rw
If a bridge falls down even when all the contractors are certified, are you still allowed to sue the engineering company? If so, doesn't this mean that true accountability comes from results, not certification? Yes, but see my comments below.
Certifications are a filtering process. By themselves, they don't help much.
Exactly.
Combine with liability (and I am a professional software developer advocating this, btw), and you get a much more reliable process. Half the problem with the IT world at the moment is that it's too easy to shrug and say "we stuffed up, and it'll cost you this much to get us to 'fix' it".
This is where we differ. I say don't bother with certification, but focus all your efforts on accountability for results.
-- SteveHowell
Ah, but accountability is what drives the need for certification. If you are personally accountable for something, the law can say that you can't do it unless you can cover the liability. Given the size of lawsuit payouts these days (especially in the US), this means that the law can force you to have liability insurance. Now, insurance companies look to minimize their exposure. As a result, they don't want to insure bad risks. Nor are they going to spend six months to a year evaluating individuals for their skillsets. So, the instant programmers become liable for their work, the insurance companies are going to want certifications, backed by a relevant professional association. If the insurance companies decide that the certifications are too weak (read: they lose too many cases), they can lean on the professional association to do something about that, whilst raising premiums at the same time.
So: the bridge collapses, you sue the engineering company you contracted to build it. When you sue the engineering company, they normally roll over and sue the engineer who signed off on it. Then, they apply to get the two cases merged, and take on the defense of the engineer, because the company is the one paying the liability insurance (and will be forced to pay the increased premiums a lost lawsuit would result in). Because this last action is so common these days, it's often done before the case hits the courts.
So, to get back to the point: good certification processes will do a lot to professionalize the software industry. If we don't do it, sooner or later we will become liable for our mistakes (indeed, for life-and-death situations, we already are). Once this happens, insurance companies will ram certifications down our throat.
It would be good if we already have good certification processes at that point in time, because otherwise we will get bad ones that will severely hamper the profession and the industry (the two are distinct).
Certification without accountability is meaningless. Accountability without certification will merely result in bad certification. The current situation (of essentially no liability) is not a permanent one, no matter how clever the lawyers who write the licenses are. -- rw
[Robert, I went back today to clean up my thread mode comments that had been here. Please make sure that I restored your original prose correctly. I had broken up some paragraphs when injecting comments. -- SteveHowell]
The current situation is not a situation of essentially no liability. Companies get sued all the time, and even when they don't, loss of reputation is an incredible deterrent to doing bad work. Companies have a strong incentive to hire good developers already, but some companies screen more effectively than others. There is no proven correlation between a company's ability to screen employees and a company's willingness to rely on external certification processes. If there's any correlation at all, I suspect it's an inverse correlation. -- SteveHowell
This page is hilarious! Does Bristol-Meyers Squib "certify" your doctor? "Certification", as practiced by IBM and Microsoft, is a blatant scam intended to generate revenue while they coerce practitioners into conforming to the certifiers worldview and offering the certifier's products. Have you looked at any "Certification Test" offered by IBM? Have you looked at the cost?
In my opinion, companies should be doing exactly the reverse of the "certification" scam. Every practitioner should receive free evaluation copies of tools, especially the expensive ones. If a vendor wants to familiarize us with a particular tool, THEY should pay US to attend the workshop that promotes it. If a neutral certification standard existed, then these offerings might show how a particular tool helps a practitioner achieve it. I would have much more credibility to my clients if I had received and been paid for full training in the Borland, Symantec, Sun, and IBM enterprise Java offerings. I could then, with credibility, do a realistic contrast-and-compare among them for a client making a choice.
I think that such comparisons are precisely what these vendors are hoping to avoid with "certification". The agenda is clear -- Microsoft wants to strengthen their domination of the market by making it impossible to support Microsoft products without their certification. They want that certification to be so expensive and so labor-intensive that few developers will be able to be similarly familiar with competing offerings. I find this blatant attempt to manipulate the market appalling, but not surprising. What does surprise me is the apparent willingness of our community to silently allow it to happen, or even embrace it as a good idea. Just how naive are we?
The closest analogy to this scam I can think of is the car companies who send mechanics to become Chrysler-certified (or whatever). Surely we can all see that the intent is to squeeze out independent mechanics, in favor of dealer "service" centers and their exorbitant rates and prices. Is that really how we want our industry to be?
I will continue lifting a very clear middle finger to every corporation that asks me to pay it in order to become "certified" to promote its products.
When the certification authority is a neutral, not-for-profit organization such as the ABA, AMA or similar body (the ACM comes to mind), perhaps the idea will be at least worth discussing.
-- TomStambaugh
Tom, I personally agree... the certifications have to be from a neutral, non-profit organization, like the ACM. That's what I said right up the top. -- rw
Comments about Java Certification moved to IsJavaCertificationWorthIt
Analogy to Teacher Certification
It sounds like Sun has created a good test. If software certification tests develop reputations among developers for being comprehensive and fair, then there will certainly me more pro-certification sentiment than you see now in our field. Also, hiring managers will eventually learn which tests show real knowledge.
I still, however, view software developer certification to be a lot like teacher certification. Teacher certification processes are not completely without merit, but at least in the U.S., I perceive that teacher certification processes filter out as many good candidates as bad ones. Software certification would do the same thing, I fear. -- SteveHowell
My issue with certification for software engineers versus civil engineers is this:
When a civil engineer arrives, he gets to design a bridge. He also gets to be held responsible if the bridge falls down. he does, however, get to dictate things like the thickness of the girders and what they're made of.
In our business, I find that far too often one arrives to find the customer wants a bridge, but wants a bridge made out of drinking straws because they bought a load of them because it looked useful... Often they only tell you this after you've signed the contracts and after you've done a load of work, whereupon you're free to walk away, as long as you don't mind not getting paid for the work so far.
Software engineers aren't respected enough that when we say "You can't build a project like this with tool X" people actually listen. That's why companies hire C++ developers, rather than hiring a developer, showing them the problem and asking them what language would be best to solve it in. Instead, companies write things in C++ because.. they always have done. Or because Perl is too scary.. or anyone of a number of reasons not based in any actual technical logic.
Civil engineers do not get hired on the basis of their experience working in, say, concrete. They get hired on whether they've done a lot of bridges before or not, then they get to pick if they're using steel or concrete for this one. They also don't get arguments like "Oh, but already bought all the concrete" or "We've been told concrete isn't a good bridge material so we've banned anyone from working in concrete" or "We don't have anyone here who understands concrete structures very well, so you can't use it."
-- KatieLucas
I think Katie wins the prize. The marketplace (our clients, employers, et al.) don't appear interested in certification/liability because it would give us the power to do the job right; not based on the latest fads. -- JeffPanici
TomDeMarco on Decertification: http://www.systemsguild.com/GuildSite/TDM/certification.html
"The case for certification made by Ralston, Mead and also by Patricia Douglas goes something like this: Poor old Citicorp and poor old Aetna and poor old Microsoft really can't tell if the people they are thinking of hiring are good, competent, educated programmers or lazy, uneducated, even unscrupulous types, so what should we do? How about we appoint an august elite (made up of our own august selves plus some of our august pals) to judge. We will divide the world into betas, who will be allowed to work in the field and gammas, who will not. In the process we will be demonstrating that we ourselves are alphas. What a brave new world!"
I was neutral on certification before reading that. Now I'm afraid. -- PhlIp
Certification is not a replacement for general experience and perhaps not even specific tool experience. But, given a choice between two candidates with equal experience, I think most would agree that the cert tilts toward their favor. In a competitive job market where there are plenty of candidates, it may make some difference. It may give you that small percentage boost to set you just above your competitors.
Any thoughts on the IEEE Computer Society's CertifiedSoftwareDevelopmentProfessional?? Good on you, if you can afford the time and money. Seriously I read this kind of thing is generally useful for getting entry level jobs, and that lots of aspirants for those jobs already have certifications. I think personally it is probably a better alternative to going to universities, for people not pursuing an academic career later on.
MicrosoftWay is changing
In Oct05 MS is said to have recognized there needs to be "better alignment" between training programs and job needs. And they have come up with "light weight" certifications and some with more lab / practice components.
See
Ed Tittell advice
Ed appears in newsletter and publication columns to respond to certifications over many years. A few samples:
See also: JustaSoftwareEngineer, where we went 'round on this topic, including McConnell's stuff from AfterTheGoldRush. --RandyStafford
See also MicrosoftCertifiedProfessional