Slashdot Mirror
Should Programmers Be Certified?
An anonymous reader wrote in to send us
For Coders, a Code of Conduct (from
the NYT so free registration is required). It says that
an engineer needs a license to work on a bridge, but
programmers work unlicensed all the time. What do you
think?
If, in a free market, there is a demand for quality in software development, then surely organizations will arise that offer various certification programs.
Netware and Microsoft have been doing this for years.
So, certification would be inevitable: it's just a question of whether it matters to a particular customer.
Licensing, on the other hand is a beast of a different colour. Licensing means that you can't work without a license. This has no place in a free market, and is usually advocated by those that have a vested interest in controlling the size of the market: unions, doctors, and lawyers do this, with the necessary government 'help'.
The argument usually goes something like this: "With licensing, we can ensure the level of quality you're gonna get from someone in this profession". Of course, this is bogus, since all it guarantees is that a licensed programmer is, well, licensed. The enticement is that a potential employer or contractor does not have to evaluate skills for themselves. Who controls the licensing board, and what is in its best interest?
As with all things that depend on government force for enforcement, such a scheme is not likely to work well: good programmers that can't afford to pay the licensing fees won't get licensed, and bad programmers can lobby to keep good ones unlicensed. The production of free software might even be outlawed (much as practicing medicine without a license is).
With certification, the certifying board has to compete with other certifying boards and remove any possible question of inpropriety, lest it's reputation suffer.
Traditionally, certification has come from Universities (originally for philosophers and medical doctors), trade schools and apprentice programs, and more recently, equipment manufacturers (the guy who works on my car is "certified" by the auto maker to know what he's doing).
We have no need for licensing in this business.
In Liberty, Rene
As a big establishment institution it is not surprising that the Times prefers to talk to officials and not people who do the work. In my experience programmers are much more quality conscious than either management or customers, who for their own good reasons are cost conscious. To certify programmers without having a "building code" to enforce higher standards would not alter the current situation, but it would remove a a lot of talent from the field. Think about it: mediocre programmers with credentials can find jobs. Lacking credentials, you won't be able to find work without some obvious talent.
The License of which you speak applies to the medical and legal fields, but not engineering.
A Certification OTOH is a piece of paper that qualifies one to use a particular tool.
What we're talking about here (NYT) is a Certification of Professional Competency, not a License to practice or a Certificate of Tool Awareness, if you will.
The CN{A|E} and MSxx 'certificates' are tool awareness leaflets that mean that an employer doesn't have to worry about you not knowing how to use a particular tool. You take an MSCD and put him in a Linux environment, and you'll see what that paper is worth.
Now, the Certificate of Professional Competency is something else entirely. Any degreed engineer knows about the decomposition of forces, and can tell that a particular design simply will not stand. But a PE will have passed tests to guarantee that his/her designs will not only stand under designed load, but under a variety of additional conditions. Also, a PE's design will FAIL-SAFE, rather than in a spectaculary disastrous manner (Gallopping Girdy comes to mind).
In the context of the software industry, a Certificate of Professional Competency has nothing to do with the development tool or language. It has to do with the robustness of the conceptual design. A PSE would know implicitly what designs are suitable solutions to a particular problem. A PSE certification would give an employer the assurance that this person does good work - and is not (pardon the term) a hack.
The concept of the Professional Certification has been bastardized by companies such as Microsoft, Novel and Sun (Java Cert? PUHLEEZE!) to convince management types that the holders of these leaflets know what they're doing. All these certs mean is that someone paid, sat, and passed.
A PSE would know, through their education and certification process, why MS-Winders is rickety and why X is a monument to great design. A PSE would not ever produce code that locks the machine, leaves a gaping security hole, or shows you a blue screen of death. A PSE would do this by design, and not by a series of fixes, patches and upgrades.
A PSE would not necessarily know Java or C++ or Smalltalk, but rather OOP - inside and out. They would not necessarily know x86 or 680x0, but the crux of ASM.
PSE development, unfortunatelly, does not mesh with OSS. It requires careful review, strong-arm process and centralized development. And for some applications, this is the way to do it.
Now for the olive branch. Many developers have what it takes to be PSE (as I define it), but all PSE's would be - by definition - great developers.
Employers whose projects carry enormous responsibility, would seek out staffs of PSE's, or would put PSE's in crucial locations within the organization, as sanity-checks on the work done.
As for who is in control of the licensing board.. Well, the industry as a whole, as in all others.
-- What you do today will cost you a day of your life.
There are different arena's one can code in. No one is going to die if their word processor crashes. In such a situation one is free to choose another word processor.
If a service is being contracted for the people from a government and human health issues are at hand then the people have a right to require that the engineer, whether he be a civil engineer or a software engineer, has proven to them that he can complete the task with safety and has the skills to show them the numbers that make it safe.
This is akin to verifying the correctness of code (mathematically proving that it cannot fail), an incredably extensive and expensive process. But sometimes it needs to be done. An exam such as the Professional Engineer exam is an attempt at making sure the people who work on these projects that affect the public know when and how to do this.
Testing code relentlessly is one thing, verifiying it's correctness is another.
They each have their arena.
Moeses
Equating "coders" and construction engineers is not the right comparison. The programmer is more akin to the person pouring the concrete per a good blueprint. When I have seen software projects fail, it was traceable to ill-defined requirements, poor system engineering, or inadequate software architecture. What is needed is a better method of defining a blueprint for software.
Most schools do not teach the software lifecycle. We do not need to license people in C, C++, Java, etc. We need to train/certify people in understanding requirements and designing software that meet these requirements (instead of meeting the latest trend or technology). We also need to better define the equivalent of a blueprint for software. We should settle on a standard (e.g. UML although not necessary so o-o geared) and then train/certify people on that standard. This will not be subject to the frequent technology turnover seen for implementation. Part of training must include how to form a test plan based on the requirements. Then the output of the programmers can be "certified" against the requirements, this being the proper test for the programmer's work.
The main failure of MS Windows is to concentrate on "neat" GUI features (a "trend") instead of basic requirements like availability and reliability. There is no word-processing requirement for a help window to grow from/fade to a corner of the window.
The success of Linux starts from the focus on basic requirements. Linus starting writing what he needed, not something he thought someone might consider "neat". The last major requirement for Linux is operability, esp. ease of use for the less technical. The challenge in meeting this is that it is as not much of a requirement for the people implementing it.