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?
as what Im not sure
the question here is... who makes the test... who decides what "good programming practices" are.
I dont know about you, but I realy dont want to see a world where everyone writes code the same way... its unproductive and stifles creativity and innovation. (esp if everyone wrote code like MS:)
on the otherhand, if I had faith that it could be done right it would not be so bad...
the most important thing to remember though is that quaility of code does not come from the skill of the programmer, everyone makes mistakes (hey, even Mel had a bug in his code, what make you so special) quality code comes from a good process of design implementation and testing, including CODE REVIEWS!
I dont know about you, but I certainly wouldnt want to write code for a life support system and not have someone review my work heavily before it was put into use.
perhaps it would be better to focus on certifying companies (or project leaders) in this way... focusing on process... of course certification is only necessary for "important" progects, ie life and death... cases where liability is a serious issue (much like the engineering profession)
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
The next Cmdr Taco duplicate will be ready soon, but subscribers can beat the rush and see it early!
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
"The people who code for the radar systems in airports, for example, do you want these people to walk in with bare minimum of knowledge and write faulty code?"
Software along the lines of an airport radar controller is going to be contracted out as part of a total system design (if the contracting authority has any competence at all). Hardware, software, backup systems, performance specs, acceptance criteria, etc. are all going to be part of a single project, and the ultimate documents for that project are going to be signed off by a registered Professional Engineer (PE).
The PE can be held individually liable for his work, so he is going to need indemnification by his employer. His employer in turn will lay off that risk to an insurance company, and the insurance company will demand audits, proof of competence, demonstrated capability to carry out similar projects, etc. That's how it goes in the real world of Big Stuff.
The PE (slash project management team) probably isn't going to be able to examine every line of code, or necessarily _any_ of the code him(them)self. But you can bet he will take steps to make sure that quality and capability are there.
Even as a person on the PE track (which I am), I acknowledge that there is an element of market control / guild-ism in the process. However, before you squeeze the trigger on the flamethrower, please spend a few minutes in a good engineering library reading back issues of Scientific American from the 1870-1890 time period. Read carefully the accounts of steam boiler explosions and the death and destruction they caused for many years. Then if you have a few extra hours, scan through the "History of the ASME Boiler and Pressure Vessel Code". Those boiler explosions, and the effort that had to be undertaken to get them under control, are the direct ancestors of the PE process. And brutal, heavy-handed government regulation turned out to be the only way to bring the body count down.
Hmmm, in terms of accepting responsibility for quality of work, does that sound like any industry we know today? I am personally not advocating that the PE regulations be extended to the software world, but after rebooting Windows 95 for the 5th time today I can see why some might.
sPh
Uhm Not quite!
I'm a practicing electronic engineer in the
computer industry. I don't have a PE, and
don't need one to pursue my career.
The poster states that passing a PE examine
GUARANTEES that the design will be fail safe.
This is demonstrably false. I can show you
any number of structural designs that have
failed, yet were designed by PE's. They didn't
fail safe either, people died.
Passing the PE examine doesn't ensure that I
am competent to do design of some nature. It
shows that I am good at taking tests on
material I only know fresh out of college.
For that matter, the PE license (and it's a
license in my state...this varies from
state to state) was only established as
a "gate-keeper" mechanism to try to ensure
some minimum level of competency. It doesn't
really achieve that either. My basic
complaint with the system is that they don't
test engineers on the fields they are going
to practice in... why does a computer design
engineer need to have a structural engineers'
understanding of statics or dynamics?
The bottom line is that this system operates
mostly because it already is an established
bureaucracy. I see no reason to extend this
system to programmers as well!
To take a different tack - a professor of
mine once defined those in the "professions"
as people who have "dangerous knowledge." I
think this is a good operating definition.
Consider - would you want me to use a knife
on you to take your appendix out - I'd be
dangerous - I don't have the requisite
training or experience to accomplish the
task. So professionals are keepers of
dangerous knowledge.
To extend this definition to the programmers'
world - are there programs that require
"dangerous knowledge." Well - there ARE
programs operating in environments that
are "life critical." There could be a
case made to extend "professional licensing"
to just these areas. Writting operating
systems to handle my game playing requirements
don't fit the requirement! Writting real-time
OS's to control a nuclear reaction might!
Even then, I don't think this is needed
or desirable because I don't think you can
test for "minimum competency." I don't think
this screening mechanism works.
Have you compiled your kernel today??
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.
In the case of doctors or lawyers, the buyer doesn't even have the skills to make that evaluation themselves. It makes a lot of sense to license doctors or lawyers to ensure minimal competency. The cost of information in that case could be life or liberty. In other cases, society may determine that the costs of licensing are small compared to the costs of forcing everybody to evaluate professionals for themselves.
I happen to agree that for programming, we do not need licensing. But the reason is not that licensing in general is a bad idea, but that the details of the market for programming services are different. Unlike a sick person trying to find a good doctor, a manager of a software development team has both the skills and the power to evaluate candidates for programming positions.
Not every engineer needs to be a professionally licensed one. Only those whose work affects the safety of people, or is Federally funded, or has HUGE money riding on it; or those who are the final authority on the product, need to bear ultimate responsibility for their work - and these are the ones who need to be certified.
The engineers who design nuclear power plants, for example, need not be certified - because the process they are bound to follow already is - and the number of redundant checks on their work is exhaustive.
So it should be with software engineers. People whose scope has a public safety effect, great financial liability, or is tax-payer funded/government contracted, but whose work does not undergo exhaustive and redundant SQA and V&V processes; should certainly be certified.
Note: Professional engineering certification is not the same as a VBA cert, or even a CNE - though the CNE comes close. Professional certification involves sound design principles, conservative estimation methods... Much more abstract concepts than knowing the version of the tool you use.
Certification is public assurance that you are competent to bear the responsibility of the task. If the worst outcome of the failure of the task, is not "that bad" (ie no public safety compromise, no property damage, no POed taxpayers not re-electing the people that gave you the contract) than simple insurance or a disclaimer will do.
This is very hard to achieve in the software context, but I suppose that a simple analogy would be: design methodologies that include - GUARANTEED BOUNDS CHECKING, NO SIDEFFECTS, NO MEMORY LEAKS, FAILSAFE OPERATION, REDUNDANT BUT DIVERSE IMPLEMENTATION OF CRITICAL ALGORITHMS AND SYSTEMS - would qualify one for professional certification (provided these are not language specific and on the core level of the developer's understanding of his/her field).
-- What you do today will cost you a day of your life.
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
I think the bridge metaphor breaks down pretty quickly...a bridge is a physical thing that can be objectively measured. A bridge goes through several "inspections" by disinterested or hostile others. A bridge is expected to last 50 to 100 years.
:)
Anyone that ever looked at some of the theoretical implications of say proving the "correctness" of a program knows that the objective inspection is basically impossible. The others are obviously outside the realm of progrmaming. So what is the idea behind the certification/license issue?
Are we trying to prevent studip people from writing code? Then we would need to prevent all the various software warehouses from selling a copy of Visual Stupid (you pick) to any and all suits and programmer-wanna-be's. That would be a good thing for several reasons.
If the idea is to give some malcontent reason for a lawsuit, well we already have enough of them to keep the courts busy for the next several millenia.
I like the idea of the guild though...self directed, self fulfilling, able to bring along the journeyman to the level of master with a known process and a mentoring methodology...Yeah I like that idea
I find the idea of requiring certification a really sad idea. I am happy to be in programming, because i enjoy doing so, and i have been doing it as a hobby since i was 9 years old (i started on a franklin ace 1000).
I came from a poor working class family, and i couldn't afford to go to college, and without that education, there are many fields that are instantly closed off to me... I would have like to have gone, but i just couldn't. I have been working as a programmer for a local company for the last 3 years. I've done embedded microcontrolled code, i've done windows UI code, i've done database coding. I have always recieved the needed training at work, (usually in the form of a textbook and some time to try stuff out).
I cringe at the idea of regulating this field, because it is one of the few remaining fields where a genuine interrest in the work (and possibly an apprenticeship) can get a job that you can support yourself and a family on. It's one of the few fields that you aren't locked out of instantly if your parents can't afford to send you to college. It's one of the few fields left where even though many people look for those with degrees, if you have enough work experience you can still have a chance.
Loosing this freedom in a blind rush to regulate would be a very sad thing.
---
Play Six Pack Man. I
The first, point, similar to that brought up by a previous poster, is that the ladder of programming difficulty/competency has many rungs, and those on lower rungs don't always realize how many rungs are still above them. It's possible to make very rapid progress learning to program, and the most visible results tend to occur at the earliest stages. So someone just learning sees that in a very short time they've learned to produce something that _looks_ 90% similar to what the pros do, and they think they've learned 90% of what there is to know about programming. They think that a license can't be worth much if they fulfilled 90% of the requirements in a few weeks, and they also have trouble accepting that there are still meaningful distinctions to be made between programmers with more experience than themselves.
;-) Basically I think this view is most commonly held by those who think they're super-studly programmers because they can hack a little JavaScript or whatever but don't do very well when real programming knowledge is required because they don't even understand what the important problems/issues in real programming are. The problem can't be with them, of course, because they're elite, so it must be that the evaluation methods are flawed. I think the real pros are more likely to accept the possibility that software engineers' levels of competence can be evaluated pretty effectively, and concentrate on different arguments against licensing or certification.
The second point is that many posters here seem to be arguing from an unstated belief that it's not possible to evaluate programmer skill in any meaningful way whatsoever. Yes, I know some are presenting arguments in different directions, but the most common seems to be "tests are meaningless". I could be polite in my response to that, but this is slashdot so why bother?
Personally, I don't much like the idea of government regulation and such, and a single written test or series of tests doesn't seem useful to evaluate someone's skills across the whole spectrum of what software engineering encompasses. However, I kind of like the idea of a "guild hall" system in which a local group of "master craftsmen" who are actually familiar with an individual's work (not just coding, but also specification, testing, scheduling, etc.) can confer journeyman status or higher, and in which the _customer_ can decide what their requirements are for involvement or engineers at some level requiring such proof of competence.
Slashdot - News for Herds. Stuff that Splatters.
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.