From: MarkusSchaber on

On 10 Feb., 22:53, Andy Champ <no....(a)nospam.invalid> wrote:
> Can any locksmith or
> burglar alarm maker guarantee that a building will withstand all attacks
> for 12 months?  _That_ is the equivalent of withstanding all virus
> attacks for 12 months - and it's on a far simpler system.

Maybe not the locksmith itself, but there are insurance companies
which calculate how high the risk is, and they take that liability.

For locks, cars, even airplanes, insurance companies do that all the
time. But there are only a few cases where this is done for software.

From: Arved Sandstrom on
Seebs wrote:
> On 2010-02-10, Arved Sandstrom <dcest61(a)> wrote:
>> Seebs wrote:
>>> I agree. I just don't think that rants about liability or certification
>>> are going to do anything. Neither of those has a thing to do with learning
>>> to write more reliable software.
>> Well, yeah, it does. Unless you believe that most software developers
>> and their employers are going to spend the extra time and money to do
>> all these things out of the goodness of their hearts. We already know
>> that the market will not force software quality to improve - it hasn't
>> happened yet.
> 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

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.

From: Arved Sandstrom on
Brian wrote:
> On Feb 10, 4:18 pm, James Kanze <james.ka...(a)> wrote:
>> On Feb 10, 10:03 am, Malcolm McLean <malcolm.mcle...(a)>
>> wrote:
>>> On Feb 10, 1:02 am, John Koy <John....(a)> wrote:>
>>> Arved Sandstrom wrote:
>>>> As long as we disclaim all liability and give no warranties
>>>> for the solutions/products we build, SD cannot be an
>>>> engineering field and the term "software engineer" remains
>>>> as an oxymoron.
>>> Basically no-one knows how to built bug-free software, so the
>>> lability exclusions are necessary.
>> Basically no one knows how to build 100% bug-free anything.
>> Witness Toyota. Globally, in fact, you can probably do better
>> with software than with most other things. And I've never
>> worked on a project where there have been liability exclusions
>> (which probably aren't legal anyway).
> Software from Ebenezer Enterprises is free. I think only
> an idiot would attempt to sue us for a problem they find
> in the software. I think the same things goes for Boost.
> I don't think they've ever been sued for defects.
> Brian Wood
> (651) 251-9384

Free (as in beer) software brings up an interesting set of arguments. If
I understand your point as being, if a product is free how can one
possibly sue the maker of it for flaws in the product? Correct me if I'm

I have my own thoughts on this topic but I simply want to make sure what
we're discussing.

From: Dancing Fingers on
For me, a non-pro, it's like solving a crossword puzzle. You're
trying but can't quite figure it out. But when you finally do it's a
huge rush and you can't wait for more.

OMG I'm addicted to programming -- my wife was right.

From: Nick Keighley on
On 10 Feb, 10:42, Malcolm McLean <malcolm.mcle...(a)>
> On Feb 10, 12:29 pm, Arved Sandstrom <dces...(a)> wrote:

> > In other words, we have adequate processes available but tend not to
> > adopt them. And _then_ because the products are seriously flawed we
> > disclaim liability because the products are in poor shape.
> > We need to get pushed from the outside, by purchasers of our software.
> > Unfortunately that hasn't happened.
> Software management is not so stupid.

sometimes it is. Sometimes quality is seen as being too expensive. The
cost of a pissed off customer isn't always factored in.

> If adequate procedures were
> available that could ensure bug-free software, at reasonable cost and
> time, they they would have been adopted.

they are available, they do have reasonable cost (in many fields) and
they have been adopted.

Telecommunication systems mostly invisibly work. There's a good reason
for this.

> Except in a few areas
> customers would soon shy away from 'no warrantry including the implied
> warrantry of suitability for any particular purpose' products.

we've pretty well brain washed the consumer to accept this as

> The fact is that many many formal methods are in existence. Some of
> them might work, to some extent, and in some circumstances. But none
> have really proved themselves when it comes to the acid test of
> developing real software for non-trivial projects.

talk to the telcommunications people, talk to the military, talk to
avionics and space, talk to automotive (ok, bad example!).