Seebs said:
Not in general, but:
1. Some people will do these things because they believe it is important
to do their work to the best of their ability.
2. Some people with contracts and such in place will still produce shoddy
code.
In short, while there's certainly a correlation, liability and certification
are neither necessary nor sufficient to produce reliable software. Insisting
on them strikes me as missing the point; they're a proxy value at best for
the actual goal.
-s
I agree with your specific statements. It's impossible not to - I see
evidence often enough of software developers who have no relevant formal
education, have no certifications, and have only OJT, who nonetheless
have applied themselves in their own time to study their field. These
are the people who read the formal language and API specifications, own
copies of books on concurrency and software testing and software design,
regularly read the better programming website articles, and subscribe
to good articles. In fact, in some cases people who follow programming
NGs on Usenet.
Generally speaking the majority of programmers who do these things do
have some relevant formal education, and often certifications, but since
currently a CS degree rarely prepares a person to be a good software
developer it's not an important factor: what counts is the other stuff I
mentioned.
For sake of argument the fraction of such software developers may be 1
in 10. I doubt it's more, because in my 25 years or so in the field,
spread out over nearly 35 years, I've encountered hundreds of developers
in many different employment settings as co-workers and colleagues, and
I've seen no evidence that it's higher than that.
Here's the thing: the main reason for having the codes of conduct,
required education and certifications, professional associations,
regulated professional development, legal guarantees and so forth, is to
prove to the consumer (employer of software developers, purchaser of
computer software etc) with a reasonable degree of assurance that they
are getting a known, reliable quantity, whether that be an employee or a
product. All that stuff is there is to help regulate the market in
software professionals and software itself, so that the consumer is not
flying in the dark when it comes to choosing services and products.
It's not a be-all and end-all by any means. It simply raises the bar,
just as it does in existing professions. It's defining the minimums, and
currently we truly have none.
Such a system also protects the true software development professionals.
As it is employers have a tough time selecting good people, and
consumers have very little idea of what they are getting. Shoddy
programmers can last a long time (and God knows they do), and while
they're at it they damage or destroy the credibility of people who are
really trying to do a proper job. Employers become accustomed to having
mediocre employees, and customers get used to shabby software. When an
employer gets an employee who really knows what they are doing they are
lauded as superstars - well, they're not, they're just doing their job.
And when customers get a reliable piece of software it gets 5 stars just
for being good software, which is also pretty sad.
The system should not be so hit and miss. And it does not have to be.
You're quite right in a narrow sense. If you are talking about the 10%
of developers who try, and the 10% of software shops that get it, and
the 10% of software that is truly quality stuff, they don't need the
extra push or the regulations. But the other 90% do.
AHS