Motivation of software professionals
Stefan Kiryazov
I am doing a research about motivation in software development, the
most efficient practices to motivate software engineers, their
popularity, etc.
As a part of the research, I am doing an online survey for software
engineers and managers in software development. It takes just several
minutes and filling it is a good opportunity to share your opinion
about the motivation practices being used in the software industry
today:
http://ask.wizefish.com/en/MotivationSurvey.aspx
Anyone who does the survey and leaves any contacts will be sent the
results.
Also, if someone is running a web site or blog dedicated to any aspect
of software development we can do some link exchange.
Regards,
Stefan Kiryazov
Richard Cornford
> Hi all,
>
> I am doing a research about motivation in software development,
> the most efficient practices to motivate software engineers,
> their popularity, etc.
Strange question; the most efficient motivator of professionals is
money, and money is very popular.
> As a part of the research, I am doing an online survey for
> software engineers and managers in software development.
<snip>
This would be more convincing as an academic exercise, as opposed to,
say, spam intended to encourage visitors to some web page with the
intention of gaining advertising revenue, if there were not so many
advertisements on the page.
In any event, your survey needs the addition of a large number of
"This question makes no sense" option checkboxes, as it is
unanswerable as it is.
Richard.
Jeff Gaines
<dabc5b6d-f342-466a...@a32g2000yqm.googlegroups.com> Stefan
Kiryazov wrote:
>I am doing a research about motivation in software development, the
>most efficient practices to motivate software engineers, their
>popularity, etc.
M O N E Y
--
Jeff Gaines Dorset UK
I can please only one person per day. Today is not your day.
Tomorrow, isn't looking good either.
Erwin Moller
I am in this business so I can fill in online questionaires.
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
Mick
Anthony Williams
> On Feb 5, 11:19 am, Stefan Kiryazov wrote:
>> Hi all,
>>
>> I am doing a research about motivation in software development,
>> the most efficient practices to motivate software engineers,
>> their popularity, etc.
>
> Strange question; the most efficient motivator of professionals is
> money, and money is very popular.
Whilst people like money, it's not necessary the most efficient
motivator. Developers also like interesting, challenging, varied work,
work with new technologies, flexible hours, freedom to do what they feel
is technically best without being hampered by management dictat and many
other things.
Anthony
--
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++0x thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
JR
I suggest reading about the "Two Factor theory of emotion", also known
as "Herzberg's motivation-hygiene theory". I studied this concept in
1984 for the first time, and I think it is still acceptable today.
http://en.wikipedia.org/wiki/Two-factor_theory
Cheers,
JR
John B. Matthews
<dabc5b6d-f342-466a...@a32g2000yqm.googlegroups.com>,
Stefan Kiryazov <stefan....@gmail.com> wrote:
> I am doing a research about motivation in software development, the
> most efficient practices to motivate software engineers, their
> popularity, etc.
[...]
This reminds me of "Drescher and the toaster":
A disciple of another sect once came to Drescher as he was
eating his morning meal.
“I would like to give you this personality test”, said the
outsider, “because I want you to be happy.”
Drescher took the paper that was offered him and put it into
the toaster, saying: “I wish the toaster to be happy, too.”
<http://catb.org/jargon/html/koans.html#id3141308>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
John Bode
> Richard Cornford <Rich...@litotes.demon.co.uk> writes:
> > On Feb 5, 11:19 am, Stefan Kiryazov wrote:
> >> Hi all,
>
> >> I am doing a research about motivation in software development,
> >> the most efficient practices to motivate software engineers,
> >> their popularity, etc.
>
> > Strange question; the most efficient motivator of professionals is
> > money, and money is very popular.
>
> Whilst people like money, it's not necessary the most efficient
> motivator. Developers also like interesting, challenging, varied work,
> work with new technologies, flexible hours, freedom to do what they feel
> is technically best without being hampered by management dictat and many
> other things.
>
This is definitely true for me; I will trade some pay for more
interesting work or a better working environment, at least up to a
point.
Patricia Shanahan
> Hi all,
>
> I am doing a research about motivation in software development, the
> most efficient practices to motivate software engineers, their
> popularity, etc.
I don't qualify as a software professional now, but I did work in the
computer industry for 32 years.
In my experience, software professionals are people, each with their own
motivations. Assuming everyone has the same motivations is a basic
leadership error.
That said, by definition professionals are, to some extent, in it for
the money. If they were not, they would be amateurs as I am now. How
that is balanced against interesting work, physical working conditions,
status, etc. varies.
Patricia
Wojtek
Hmmm, I have seen "professionals" who should be escorted out by
security. And then people who do it for personal satisfaction who
produce excellent code.
The FOSS movement has a mix of these two groups.
Being a professional is a state of mind rather than renumeration.
But yes, I like to eat too....
--
Wojtek :-)
Walter Banks
Stefan Kiryazov wrote:
> I am doing a research about motivation in software development, the
> most efficient practices to motivate software engineers, their
> popularity, etc.
Watching it all come together in a project after 40 years still
has the same excitement. I resigned from a good job 30 years
ago to program again as a career telling colleges at the time
that I may never work again but I am playing 50 or 60 hours
a week at something I love to do.
Regards,
w..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
BGB / cr88192
"Anthony Williams" <antho...@gmail.com> wrote in message
news:87ljf76...@dell.justsoftwaresolutions.co.uk...
> Richard Cornford <Ric...@litotes.demon.co.uk> writes:
>
>> On Feb 5, 11:19 am, Stefan Kiryazov wrote:
>>> Hi all,
>>>
>>> I am doing a research about motivation in software development,
>>> the most efficient practices to motivate software engineers,
>>> their popularity, etc.
>>
>> Strange question; the most efficient motivator of professionals is
>> money, and money is very popular.
>
> Whilst people like money, it's not necessary the most efficient
> motivator. Developers also like interesting, challenging, varied work,
> work with new technologies, flexible hours, freedom to do what they feel
> is technically best without being hampered by management dictat and many
> other things.
>
OTOH, many programmers may also despise anything "new" or "different", or
anything which may effect "the way things usually are".
give them something new, and they will resist, like "this is not how I
usually do things", ...
it would be like, in a college, them adding soap dispensers all over the
walls in the hallways.
then, this is unsettling, since it is well known that soap dispensers are
properly placed in the bathrooms, and so what are they doing in the
hallways?...
likewise, many may like a well-defined heirarchy of authority,
strong-seeming authority figures, and the sense of "excitement" over the
volumes of work being produced (measurable via metrics like money, units
sold, kloc written, completing various items on various agendas, ...), ...
and, granted, other people may not like this...
they might dislike, for example, being expected to stand and greet the boss
whenever he enters the room, waiting for him either to say something
relevant or to tell them all to carry on, ...
other people may also not like attending meetings for the sake of debating
over agenda items, deciding on matters of policy, ...
so, it may all depend a lot on the person (and/or, the personality types of
the people involved...).
MarkusSchaber
wrote:
> On Feb 5, 11:19 am, Stefan Kiryazov wrote:
>
> > Hi all,
>
> > I am doing a research about motivation in software development,
> > the most efficient practices to motivate software engineers,
> > their popularity, etc.
>
> Strange question; the most efficient motivator of professionals is
This was proven wrong by Science. Read Bruce Eckels excellent blog
entries about this topic, he always references relliable sources on
this subject.
Thomas 'PointedEars' Lahn
> On Feb 5, 11:19 am, Stefan Kiryazov wrote:
>> I am doing a research about motivation in software development,
>> the most efficient practices to motivate software engineers,
>> their popularity, etc.
>
> Strange question; the most efficient motivator of professionals is
> money, and money is very popular.
That would mean that the more you are paid, the more motivated you are,
which is obviously wrong. Money is only part of the equation. Money is a
factor of motivation in capitalism only because of the things that money can
buy, and which it means to others. But those things can be gained without
money as well, so you would probably be equally motivated if someone
provides them for work you have done. See, e.g., Maslow's hierarchy of
needs.
F'up2 poster
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Tom Anderson
> On Feb 5, 11:19 am, Stefan Kiryazov wrote:
>
>> I am doing a research about motivation in software development,
>> the most efficient practices to motivate software engineers,
>> their popularity, etc.
>
> Strange question; the most efficient motivator of professionals is
> money, and money is very popular.
There's a robust body of work that suggests this is very much *not* the
case. Money motivates some people; technical people are more motivated by
interesting work and respect from their colleagues.
tom
--
It is a formal cultural policy to show unreasonable bias towards any
woman who is both attractive and weird.
Saga
news:selection-20...@ram.dialup.fu-berlin.de...
> Stefan Kiryazov <stefan....@gmail.com> writes:
>>http://ask.wizefish.com/en/MotivationSurvey.aspx
>
> This survey has a strong selection bias:
>
> Real professionals are motivated by the money.
>
> But those motivated by money will not attend
> the survey as they are not being paid for it.
And those not motivated by money will also not
attend the survey because they'll think it is
offensive, catagorizing them as "non professional"
simply because they are not motivated by money.
Saga
Tom Anderson
> That said, by definition professionals are, to some extent, in it for
> the money. If they were not, they would be amateurs as I am now.
Interesting. Do you think that all the non-financial rewards that are
available (if rarely!) in industry are available in academia or on
volunteer projects?
Something i find quite enjoyable, having moved from academia into
industry, is the sense that a project is actually doing something
valuable, something a business thinks is worth money. Work in academia and
the FOSS community can be very interesting, but a lot of it feels like
farting about.
tom
--
I sometimes think that the IETF is one of the crown jewels in all of
western civilization. -- Tim O'Reilly
Jedrin
If money was the only motivating factor wouldn't we all want to be
wall street bankers instead ?
Seebs
> If money was the only motivating factor wouldn't we all want to be
> wall street bankers instead ?
If we thought we could make more money at it than we could programming. I
don't think I could. Comparative advantage ftw!
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Malcolm Dew-Jones
: If money was the only motivating factor wouldn't we all want to be
: wall street bankers instead ?
Perhaps we all do - but until we get that chance...
Roedy Green
<Ric...@litotes.demon.co.uk> wrote, quoted or indirectly quoted
someone who said :
>
>Strange question; the most efficient motivator of professionals is
>money, and money is very popular.
That may be a motivator for taking a job, but I suspect is fairly far
down the list for leaving a job.
Leaving motivations might include:
personality conflict
boredom
too much pressure
Personally, the opportunity to do something I had never done before
was always the top priority. Employers usually want people who have
extensive specific experience.
In hiring, my main interest was loyalty. Employees don't get really
useful until after the first year. I don't expect them to hit the
ground running. I anticipate investing considerable effort in training
them. I looked for reasons why they would likely want to stay.
--
Roedy Green Canadian Mind Products
http://mindprod.com
You can�t have great software without a great team, and most software teams behave like dysfunctional families.
~ Jim McCarthy
Hillbilly
"Richard Cornford" <Ric...@litotes.demon.co.uk> wrote in message
news:62cdf238-b5ce-4d42...@k41g2000yqm.googlegroups.com...
Joe Wright
> On 2010-02-05, Jedrin <jrub...@gmail.com> wrote:
>> If money was the only motivating factor wouldn't we all want to be
>> wall street bankers instead ?
>
> If we thought we could make more money at it than we could programming. I
> don't think I could. Comparative advantage ftw!
>
> -s
We could write a program that makes all that money automatically. A
programmer with tools envies no one.
I started writing software for money almost 30 years ago as a freelancer
implementing a BIOS for a CP/M system. The project was very successful and
the pay was pretty good too. The task was challenging (I had never written
a BIOS from scratch) and fun. That it paid money was important. The amount
of money was less so.
I, and most programmers I know, program all the time. Some of it we get
paid for but most of it not. I live in fear that one day the boss will
discover that I would do all this for nothing.
--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."
Seebs
> I, and most programmers I know, program all the time. Some of it we get
> paid for but most of it not. I live in fear that one day the boss will
> discover that I would do all this for nothing.
The key is that I wouldn't do this *specific* programming for nothing, and
not many people want the stuff I would do for nothing.
... Actually, the chances are pretty good that more humans will use the
addon I wrote for WoW than will ever use the build system I work on at
work, but the people using the build system are willing to pay large sums
of money for it, while the addon users are mostly limited to maybe donating
a buck.
Nick Keighley
> Hi all,
>
> I am doing a research about motivation in software development, the
> most efficient practices to motivate software engineers, their
> popularity, etc.
>
> minutes and filling it is a good opportunity to share your opinion
> about the motivation practices being used in the software industry
> today:http://ask.wizefish.com/en/MotivationSurvey.aspx
>
> Anyone who does the survey and leaves any contacts will be sent the
> results.
>
> Also, if someone is running a web site or blog dedicated to any aspect
> of software development we can do some link exchange.
>
> Stefan Kiryazov
James Kanze
wrote:
> On Feb 5, 11:19 am, Stefan Kiryazov wrote:
> > I am doing a research about motivation in software
> > development, the most efficient practices to motivate
> > software engineers, their popularity, etc.
> Strange question; the most efficient motivator of
> professionals is money, and money is very popular.
Yes and no. Obviously, money plays a role---some of us have
expensive habits, like eating regularly, that have to be paid
for. But it has its limits, and I've rarely seen money alone
motivate the best performance (in anything).
--
James Kanze
James Kanze
> Richard Cornford <Rich...@litotes.demon.co.uk> writes:
> > On Feb 5, 11:19 am, Stefan Kiryazov wrote:
> >> I am doing a research about motivation in software
> >> development, the most efficient practices to motivate
> >> software engineers, their popularity, etc.
> > Strange question; the most efficient motivator of
> > professionals is money, and money is very popular.
> Whilst people like money, it's not necessary the most
> efficient motivator. Developers also like interesting,
> challenging, varied work, work with new technologies, flexible
> hours, freedom to do what they feel is technically best
> without being hampered by management dictat and many other
> things.
Amongst other things. Two of the most important motivaters are
peer approval and admiration, and personal satisfaction with the
results.
--
James Kanze
James Kanze
[...]
> That said, by definition professionals are, to some extent, in
> it for the money. If they were not, they would be amateurs as
> I am now. How that is balanced against interesting work,
> physical working conditions, status, etc. varies.
I'm not sure if the word "professional" has the same conotations
in English as it does in French, but from the French meaning, I
don't think you can be truely a "professional" if you're only in
it for the money. "Professional" implies being paid for what
you do, but it also implies a certain degree of personal
standards with regards to quality and such---a "professional"
will take pride in his work.
--
James Kanze
Alf P. Steinbach
I agree.
But strangely, one thing that motivates me is apparent peer disapproval. For in
many social environments (last week or so there was a damning report about this
kind of environment at the University of Oslo, happily I'm not there) the art of
put-down'ing and dissing is key to personal success. When someone else does
something really good then put-down'ing becomes necessary and the default
response. Thus, when I get critique that has more emotional impact than
technical I concentrate on the technical points. Then, interpreting those more
technical points in a kind of inverse-picture way, I know what's good.
Of course, that's part of the personal satisfaction motivation, but I think it's
interesting that personal satisfaction, knowing that you've created something
good, in some/many environments can be directly incompatible with peer approval.
And for me personal satisfaction weights more.
Peer approval would in most cases just say that I'm conforming, which is not
something that I'd be proud of; it's something I strive to avoid. But in some
cases approval is really nice. E.g., a few times you've stated that I'm pretty
good, or words to that effect, which coming from someone that one respects is
uplifting in a way; likewise, once, many years ago, I had a dispute with one
very well-known C++ expert over in clc++m and wrote some things that I really
shouldn't have, the mod apologized for accepting the article by saying that he
didn't read closely because it was two "C++ experts" discussing things, and that
helped much, otherwise I might have stopped posting... :-)
Cheers,
- Alf
Malcolm Dew-Jones
In English also, "professional" implies "a certain degree of personal
standards with regards to quality and such".
As with many words the different facets of its meaning can appear to be
both ambiguous and contradictory, but I think that in the long run being
"professional" in the sense of earning money requires "professional"ism in
behaviour (and vice versa), so ultimately the meaings do not conflict
(even though they can in the short term).
$0.10
Dirk Bruere at NeoPax
Depends.
Right now I am primarily motivated by money, or at least the lack of it.
--
Dirk
http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.blogtalkradio.com/onetribe - Occult Talk Show
Seebs
> Right now I am primarily motivated by money, or at least the lack of it.
Money or the lack thereof can motivate you to do what is necessary to keep
a job. It can't motivate you to want to do more.
$dayjob pays me enough that I don't starve; for that they get forty hours a
week and when it's time for dinner, seeya tomorrow. On the other hand,
they've been pretty good to us; they listen when we say something is
technically infeasible, they solve non-technical problems for us, and so on.
Also, some of the work is really interesting. And that's why every so often
(a couple of times a year), I sit there plugging away at something until 2AM.
:)
MarkusSchaber
On 8 Feb., 03:18, Dirk Bruere at NeoPax <dirk.bru...@gmail.com> wrote:
> >>> I am doing a research about motivation in software development,
> >>> the most efficient practices to motivate software engineers,
> >>> their popularity, etc.
> >> Strange question; the most efficient motivator of professionals is
> >> money, [...]
> > This was proven wrong by Science. Read Bruce Eckels excellent blog
> > entries about this topic, he always references relliable sources on
> > this subject.
> Depends.
> Right now I am primarily motivated by money, or at least the lack of it.
I won't dispute that money is a motivator, but it is not the most
efficient motivator. The more money you pay, the more you will attract
those developers which are purely after the money, and not the really
good ones. For the latter ones, a certain level on the paycheck is
enough to give attention to fun, excitement, atmosphere and such
factors.
James Dow Allen
Reading this thread disappointed me. :-(
Most mentioned money as the primary motive, including some
posters who *obviously* have very excellent analytic
skills and could surely have succeeded at some higher-paying
professions.
(I have my own peculiar limitations. The only higher-paying
profession where I demonstrated ability to succeed was
Blackjack! I had a brief fling with an exciting high-paying
life style, but ended up deciding the intellectual challenge
of engineering work was more rewarding.)
On Feb 7, 11:00 am, Joe Wright <joewwri...@comcast.net> wrote:
> I, and most programmers I know, program all the time. Some of it we get
> paid for but most of it not. I live in fear that one day the boss will
> discover that I would do all this for nothing.
Now that's more like it!
James Dow Allen
Dirk Bruere at NeoPax
I once joked with an employer that if he paid me twice as much I would
only have to work half as long :-)
Lew
>> I won't dispute that money is a motivator, but it is not the most
>> efficient motivator. The more money you pay, the more you will attract
>> those developers which are purely after the money, and not the really
>> good ones. For the latter ones, a certain level on the paycheck is
>> enough to give attention to fun, excitement, atmosphere and such
>> factors.
Dirk Bruere at NeoPax wrote:
> I once joked with an employer that if he paid me twice as much I would
> only have to work half as long :-)
Given that nearly nobody gives a perfect working environment, or even close,
money is the primary distinguisher. As a contract worker, I've seen a few
dozen IT workplaces. The grass is never greener. Offer me twice as much
compensation as the other potential employer and my talents are yours to exploit.
It's not that money is the motivator. The question is leading and extremely
ill cast. I don't depend on anyone else for my motivation. Money is the
decider; it decides whether and where I work. It doesn't determine how.
To get meaningful answers, the survey would have to ask meaningful questions.
--
Lew
Malcolm McLean
body which regulates itself and has the right to control entry to the
profession. For instnace I can't simply buy scalpels and antiseptic
and set myself up as a brain surgeon - I have to go throguh the
British Medical Association before they'll let me chop people up. the
same is true for lawyers, accountants, and some other more obscure
niches.
Most people aren't professionals, and the word has become misused to
mean 'skilled workers with high standards'. Bascially employers want
the advantages of professional status without conferring on their
employees the control that is the natural concomitant.
Computer programmers are rarely professionals in the true sense, but
ususally professional in the bastardised sense of the term.
Larz
I basically was never convinced that work of any sort could be fun up
to my early 20's. No one ever convinced me of that or ever thought it
important enough to ever bring up the issue of whether work should be
enjoyable or not.
I was a paper boy, dishwasher, worked on farms, retail stores etc. I
always have enjoyed being a musician I would say, but even that can be
stifling depending on the situation. At one point in 1983 or so I
decided I needed a career and took a COBOL class which to my surprise
I found software interesting. After nearly flunking out of high
school, I got a degree in CS and made the honor roll and did very
well. When i started my career as a programmer, I discovered that
managers, co workers and the business world at times can take alot of
the fun out of it. On the other hand, this led me to discover
meditation and the spiritual side of life as the stress and
frustration inspired me to take up meditating on biblical psalms,
buddhist meditation and a few yogi masters ..
Thomas 'PointedEars' Lahn
> Strictly a "professional" is someone who is a member of a professional
> body which regulates itself and has the right to control entry to the
> profession. For instnace I can't simply buy scalpels and antiseptic
> and set myself up as a brain surgeon - I have to go throguh the
> British Medical Association before they'll let me chop people up. the
> same is true for lawyers, accountants, and some other more obscure
> niches.
>
> Most people aren't professionals, and the word has become misused to
> mean 'skilled workers with high standards'. Bascially employers want
> the advantages of professional status without conferring on their
> employees the control that is the natural concomitant.
>
> Computer programmers are rarely professionals in the true sense, but
> ususally professional in the bastardised sense of the term.
Your notion of "computer programmer" is a bit outdated to say the least.
This thread was about "software professionals".
You might also want to update other parts of your knowledge:
,-<http://www.britannica.com/bps/dictionary?query=professional&header_go=>
|
| Main Entry: ¹pro·fes·sion·al
| Pronunciation: \prə-ˈfesh-nəl, -ˈfe-shə-nəl\
| Function: adjective
| Date: 1606
|
| 1 a: of, relating to, or characteristic of a profession[1]
| b: engaged in one of the learned professions
| c (1): characterized by or conforming to the technical or ethical
| standards of a profession
| (2): exhibiting a courteous, conscientious, and generally
| businesslike manner in the workplace
|
| 2 a: participating for gain or livelihood in an activity or field of
| endeavor often engaged in by amateurs <a ∼ golfer>
| b: having a particular profession as a permanent career
| <a ∼ soldier>
| c: engaged in by persons receiving financial return <∼ football>
|
| 3: following a line of conduct as though it were a profession
| <a ∼ patriot>
| — pro·fess·ion·ally adverb
|
|-----------------------------------------------------------------------
|
| Main Entry: ²professional
| Function: noun
| Date: 1811
|
| one that is professional; especially: one that engages in a pursuit or
| activity professionally
[1]
| Main Entry:pro·fes·sion
| Pronunciation: \prə-ˈfe-shən\
| Function: noun
| Etymology: Middle English professioun, from Anglo-French profession,
| from Late Latin & Latin; Late Latin profession-, professio,
| from Latin, public declaration, from profitēri
| Date: 13th century
|
| 1: the act of taking the vows of a religious community
| 2: an act of openly declaring or publicly claiming a belief, faith,
| or opinion : protestation
| 3: an avowed religious faith
| 4 a: a calling requiring specialized knowledge and often long and
| intensive academic preparation
| b: a principal calling, vocation, or employmentc: the whole body
| of persons engaged in a calling
So much for "bastardised".
F'up2 poster
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Thomas 'PointedEars' Lahn
> Strictly a "professional" is someone who is a member of a professional
> body which regulates itself and has the right to control entry to the
> profession. For instnace I can't simply buy scalpels and antiseptic
> and set myself up as a brain surgeon - I have to go throguh the
> British Medical Association before they'll let me chop people up. the
> same is true for lawyers, accountants, and some other more obscure
> niches.
>
> Most people aren't professionals, and the word has become misused to
> mean 'skilled workers with high standards'. Bascially employers want
> the advantages of professional status without conferring on their
> employees the control that is the natural concomitant.
>
> Computer programmers are rarely professionals in the true sense, but
> ususally professional in the bastardised sense of the term.
Your notion of "computer programmer" is a bit outdated to say the least.
Ivan Marsh
The 1950's were totally awesome.
--
"All right, all right, if it will make you happy, I will overthrow society."
- Philip J. Fry
Lew
> The 1950's [sic] were totally awesome.
Oh, yeah - the twin evils of McCarthyism and Communism. Racism. Sexism. The
Cold War. Superpowers playing chess with smaller countries. Wars everywhere.
Dictators. Massive stockpiling of nuclear and chemical weapons. Rapine of
the planet. The birth of AIDS. Hideous fashions.
Totally awesome.
--
Lew
Ivan Marsh
The complete lack of sarcasm...
Malcolm McLean
>
> ,-<http://www.britannica.com/bps/dictionary?query=professional&header_go=>
>
people use it. Which eventually of course becomes what it 'really'
means.
Dirk Bruere at NeoPax
Some places you go, however, you never want to return.
They are real tech sweatshop hellholes with everyone looking for a new
job. Last place like that I was at the boss said: "This project is
behind schedule and if it is not on time heads will roll. I am now off
on holiday". I suspect he returned to an empty office.
Ian Collins
> On Feb 8, 1:43 am, James Kanze <james.ka...@gmail.com> wrote:
>> On Feb 5, 3:14 pm, Patricia Shanahan <p...@acm.org> wrote:
>>
>> [...]
>>
>>> That said, by definition professionals are, to some extent, in
>>> it for the money. If they were not, they would be amateurs as
>>> I am now. How that is balanced against interesting work,
>>> physical working conditions, status, etc. varies.
>> I'm not sure if the word "professional" has the same conotations
>> in English as it does in French, but from the French meaning, I
>> don't think you can be truely a "professional" if you're only in
>> it for the money. "Professional" implies being paid for what
>> you do, but it also implies a certain degree of personal
>> standards with regards to quality and such---a "professional"
>> will take pride in his work.
>>
> Strictly a "professional" is someone who is a member of a professional
> body which regulates itself and has the right to control entry to the
> profession.
In some contexts maybe, but golf and cricket clubs had their
"professional" long before anyone thought of developing software. It
isn't the term "professional" that has been bastardised, it's "Engineer".
--
Ian Collins
Dirk Bruere at NeoPax
Come to Britain where we have "boffins" or occasionally "eggheads" and
where the gas company will send round an engineer to fix your appliance.
Or, if he cannot manage it, a technician (yes - that's what they really
said).
Seebs
> They are real tech sweatshop hellholes with everyone looking for a new
> job. Last place like that I was at the boss said: "This project is
> behind schedule and if it is not on time heads will roll. I am now off
> on holiday". I suspect he returned to an empty office.
I should hope so!
Last time we had a thing behind schedule, the management sent out a request
that we put in extra time to bring it on schedule. They had already cut
product specs in a few key places to try to make things better, and they
told us they'd make it good if we helped them out. We had very close to
24/7 management coverage, and they helped out as much as they could. And
yes, we made the deadline, and they rewarded us suitably.
The primary motivation there wasn't the money, it was the visible
demonstration that the management felt it was their problem more than ours
that the schedule had been wrong. (Note the emphasis; it was not that we
were behind the schedule, it was that the schedule was, empirically, wrong.)
Kenny McCormack
Good point. And well put.
But supercilliously quoting the dictionary as proof of one's position is
a long-standing Usenet tradition.
Dirk Bruere at NeoPax
> On 2010-02-08, Dirk Bruere at NeoPax <dirk....@gmail.com> wrote:
>> Some places you go, however, you never want to return.
>> They are real tech sweatshop hellholes with everyone looking for a new
>> job. Last place like that I was at the boss said: "This project is
>> behind schedule and if it is not on time heads will roll. I am now off
>> on holiday". I suspect he returned to an empty office.
>
> I should hope so!
>
> Last time we had a thing behind schedule, the management sent out a request
> that we put in extra time to bring it on schedule. They had already cut
> product specs in a few key places to try to make things better, and they
> told us they'd make it good if we helped them out. We had very close to
> 24/7 management coverage, and they helped out as much as they could. And
> yes, we made the deadline, and they rewarded us suitably.
>
> The primary motivation there wasn't the money, it was the visible
> demonstration that the management felt it was their problem more than ours
> that the schedule had been wrong. (Note the emphasis; it was not that we
> were behind the schedule, it was that the schedule was, empirically, wrong.)
>
> -s
The best place I ever worked was in a small R&D dept run like a
skunkworks. We reported directly to the owner and all other layers of
management eliminated. The most productive place in over 30 years of
design. All went to shit when the owner was persuaded to get in "real"
management. 3 years and the company went from $30m to bust.
Andy Champ
>
> I'm not sure if the word "professional" has the same conotations
> in English as it does in French, but from the French meaning, I
> don't think you can be truely a "professional" if you're only in
> it for the money. "Professional" implies being paid for what
> you do, but it also implies a certain degree of personal
> standards with regards to quality and such---a "professional"
> will take pride in his work.
>
There was a time when being an engineer was an important thing - and
what we do is a branch of engineering.
AKA
http://preview.tinyurl.com/ykycpgu
Nowadays an engineer is no longer someone who exercises their ingenuity,
but a locomotive driver (US) or repairman.
As time has gone by the status of engineering in general has dropped,
and I think the status of the professions in general. A bank manager
was a professional, but not likely to be particularly qualified; an
accountant definitely counted. The real money these days is made by
arbitrageurs and such who are only professional in the sense that they
are in it for the money. I suspect that most people do not have the
respect for them that a banker, lawyer, politician or doctor would have
attracted in years gone by.
Anyway - money a motivator? Only up to a point, for most people. If
you've got enough it just stops mattering.
Except to those few for whom having lots of money is an end to itself.
And in general they tend not to be technical people.
The other side of the coin is amateur - doing it for the love of it.
And I for one am glad that there are people on this group helping people
for no financial reward whatsoever.
Andy
Tim Streater
> http://preview.tinyurl.com/ykycpgu
Could do with a lick of paint.
--
Tim
"That the freedom of speech and debates or proceedings in Parliament
ought not to be impeached or questioned in any court or place out of
Parliament"
Bill of Rights 1689
Martin Gregorie
>
> In some contexts maybe, but golf and cricket clubs had their
> "professional" long before anyone thought of developing software. It
> isn't the term "professional" that has been bastardised, it's
> "Engineer".
>
That's easy: anybody who isn't a member of a recognised engineering
society should not be called an engineer and should be laughed out of
town if they call themselves one.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
James Kanze
> * James Kanze:
[...]
> But strangely, one thing that motivates me is apparent peer
> disapproval. For in many social environments (last week or so
> there was a damning report about this kind of environment at
> the University of Oslo, happily I'm not there) the art of
> put-down'ing and dissing is key to personal success. When
> someone else does something really good then put-down'ing
> becomes necessary and the default response. Thus, when I get
> critique that has more emotional impact than technical I
> concentrate on the technical points. Then, interpreting those
> more technical points in a kind of inverse-picture way, I know
> what's good.
Any commercial firm which created that sort of environment would
fail very quickly. And I'll admit that I've never quite seen it
to that point. (I have seen cases where one manager tried to
cause the failure of projects for which another manager was
responsible. But I've never seen anything similar among the
technical personel.)
I've always gotten a great deal of satisfaction from peer (as
opposed to boss') approval. And it's been forthcoming in
practically every firm I've worked in---my collegues have
thought my programs good, and told me so. Even in really poorly
run shops. (Perhaps more so in poorly run shops---in the better
run shops, it was taken for granted that everyone would write
good code, and you needed to do something exceptional to get
special approval.)
> Of course, that's part of the personal satisfaction
> motivation, but I think it's interesting that personal
> satisfaction, knowing that you've created something good, in
> some/many environments can be directly incompatible with peer
> approval.
Don't work in such environments. They're dangerous for your
(mental) health. And as long as you stick to the technical
side, they are very, very rare.
> And for me personal satisfaction weights more.
> Peer approval would in most cases just say that I'm
> conforming, which is not something that I'd be proud of;
No. But it does mean that what you've done that is original can
be understood by others. Which IMHO is good.
> it's something I strive to avoid. But in some cases approval
> is really nice. E.g., a few times you've stated that I'm
> pretty good, or words to that effect, which coming from
> someone that one respects is uplifting in a way; likewise,
> once, many years ago, I had a dispute with one very well-known
> C++ expert over in clc++m and wrote some things that I really
> shouldn't have, the mod apologized for accepting the article
> by saying that he didn't read closely because it was two "C++
> experts" discussing things, and that helped much, otherwise I
> might have stopped posting... :-)
Note that approval can come in many different forms:-). At
times, I've argued strongly with you because IMO, you opinion
counts. You're not just anyone---your knowledge of C++ (and
software engineering in general) is exceptional. So when your
point of view disagrees with mine, it worries me. Which makes
me argumentive.
--
James Kanze
Seebs
> That's easy: anybody who isn't a member of a recognised engineering
> society should not be called an engineer and should be laughed out of
> town if they call themselves one.
This strikes me as the polar opposite of an engineering mindset, which
would be that a thing is what it is, and isn't what it isn't, regardless
of any labels.
James Kanze
> MarkusSchaber wrote:
> >> I won't dispute that money is a motivator, but it is not
> >> the most efficient motivator. The more money you pay, the
> >> more you will attract those developers which are purely
> >> after the money, and not the really good ones. For the
> >> latter ones, a certain level on the paycheck is enough to
> >> give attention to fun, excitement, atmosphere and such
> >> factors.
> Dirk Bruere at NeoPax wrote:
> > I once joked with an employer that if he paid me twice as
> > much I would only have to work half as long :-)
> Given that nearly nobody gives a perfect working environment,
> or even close, money is the primary distinguisher. As a
> contract worker, I've seen a few dozen IT workplaces. The
> grass is never greener. Offer me twice as much compensation
> as the other potential employer and my talents are yours to
> exploit.
That's completely wrong. The effect of money depends on a lot
of things: someone who's just coming out of an expensive
divorce, heavily endebted, will doubtlessly put more importance
on it that a young, single person who has no debts and is making
enough to comfortably sustain the lifestyle he likes. But
environments do vary, enormously, and unless I'm under duress,
I'll always go for the position which seems to offer the better
environment. (But of course, at my level, even those positions
offer a comfortable level of life. It's generally a question of
being well off, rather than very well off.)
> It's not that money is the motivator. The question is leading
> and extremely ill cast. I don't depend on anyone else for my
> motivation. Money is the decider; it decides whether and
> where I work. It doesn't determine how.
I'll refuse jobs that aren't sufficiently paid. But I recently
changed jobs more because I was bored than because I make more
in my new job. (Formally, my income is considerably higher.
But so are my expenses---my living standard is basically
unchanged, or even a little lower than it used to be.)
--
James Kanze
James Kanze
> On 2010-02-08, Dirk Bruere at NeoPax <dirk.bru...@gmail.com> wrote:
[...]
> The primary motivation there wasn't the money, it was the
> visible demonstration that the management felt it was their
> problem more than ours that the schedule had been wrong.
> (Note the emphasis; it was not that we were behind the
> schedule, it was that the schedule was, empirically, wrong.)
Yes! I think that most people fundamentally like to help
others, in one way or another. And someone saying that they
screwed up, and asking for help, is a strong motivator for most
people. On the other hand, threats almost never work. People
don't work well when they feel threatened.
--
James Kanze
Arved Sandstrom
> On 2010-02-08, Martin Gregorie <mar...@address-in-sig.invalid> wrote:
>> That's easy: anybody who isn't a member of a recognised engineering
>> society should not be called an engineer and should be laughed out of
>> town if they call themselves one.
>
> This strikes me as the polar opposite of an engineering mindset, which
> would be that a thing is what it is, and isn't what it isn't, regardless
> of any labels.
>
> -s
Insofar as competent and professional engineering societies set real
standards for qualifications and conduct to be able to use the title
"Engineer", and insofar as the vast majority of software developers have
nothing like this at all, I see no problem here.
AHS
James Kanze
wrote:
> On Feb 8, 1:43 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Feb 5, 3:14 pm, Patricia Shanahan <p...@acm.org> wrote:
> > [...]
> > > That said, by definition professionals are, to some
> > > extent, in it for the money. If they were not, they would
> > > be amateurs as I am now. How that is balanced against
> > > interesting work, physical working conditions, status,
> > > etc. varies.
> > I'm not sure if the word "professional" has the same
> > conotations in English as it does in French, but from the
> > French meaning, I don't think you can be truely a
> > "professional" if you're only in it for the money.
> > "Professional" implies being paid for what you do, but it
> > also implies a certain degree of personal standards with
> > regards to quality and such---a "professional" will take
> > pride in his work.
> Strictly a "professional" is someone who is a member of a
> professional body which regulates itself and has the right to
> control entry to the profession. For instnace I can't simply
> buy scalpels and antiseptic and set myself up as a brain
> surgeon - I have to go throguh the British Medical Association
> before they'll let me chop people up. the same is true for
> lawyers, accountants, and some other more obscure niches.
Words have many meanings, and some professions are "reglementé".
Still, in France, I was a "profession libérale", and not a
"commerçant" or "artisan"---in Germany, the categorie was
"freiberuflich", rather than "Gewerber". These are very
distinct legal categories, with (especially in Germany)
implications with regards to how I was taxed, etc. (And it did
lead to some interesting situations in France, since typically,
as a "profession libérale", I was asked for my registration with
the professional association. Which didn't exist for my
profession.)
--
James Kanze
Phil Carmody
> Lew wrote:
>> Ivan Marsh wrote:
>>> The 1950's [sic] were totally awesome.
>>
>> Oh, yeah - the twin evils of McCarthyism and Communism. Racism. Sexism.
>> The
>> Cold War. Superpowers playing chess with smaller countries. Wars
>> everywhere.
>> Dictators. Massive stockpiling of nuclear and chemical weapons. Rapine
>> of
>> the planet. The birth of AIDS. Hideous fashions.
>>
>> Totally awesome.
>
> The complete lack of sarcasm...
No, I think you'll find that Tom Lehrer was quite active in
those days.
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
Seebs
> Seebs wrote:
>> On 2010-02-08, Martin Gregorie <mar...@address-in-sig.invalid> wrote:
>>> That's easy: anybody who isn't a member of a recognised engineering
>>> society should not be called an engineer and should be laughed out of
>>> town if they call themselves one.
>> This strikes me as the polar opposite of an engineering mindset, which
>> would be that a thing is what it is, and isn't what it isn't, regardless
>> of any labels.
> Insofar as competent and professional engineering societies set real
> standards for qualifications and conduct to be able to use the title
> "Engineer", and insofar as the vast majority of software developers have
> nothing like this at all, I see no problem here.
Membership in an organization is not the same thing as meeting the formal
standards that would be required by such an organization if it existed.
In short, if there exists a set of qualifications and conduct which would
be necessary to be a member of an organization, and membership confers the
title "engineer", then having that set of qualifications and conduct ought
to confer the title *with or without* membership in the organization.
Meanwhile, at least some members of any given organization will usually
not actually meet the nominal or formalized standard in one way or another.
Measurement by proxy is not very good measurement.
Arved Sandstrom
> On 2010-02-08, Arved Sandstrom <dce...@hotmail.com> wrote:
>> Seebs wrote:
>>> On 2010-02-08, Martin Gregorie <mar...@address-in-sig.invalid> wrote:
>>>> That's easy: anybody who isn't a member of a recognised engineering
>>>> society should not be called an engineer and should be laughed out of
>>>> town if they call themselves one.
>
>>> This strikes me as the polar opposite of an engineering mindset, which
>>> would be that a thing is what it is, and isn't what it isn't, regardless
>>> of any labels.
>
>> Insofar as competent and professional engineering societies set real
>> standards for qualifications and conduct to be able to use the title
>> "Engineer", and insofar as the vast majority of software developers have
>> nothing like this at all, I see no problem here.
>
> Membership in an organization is not the same thing as meeting the formal
> standards that would be required by such an organization if it existed.
>
> In short, if there exists a set of qualifications and conduct which would
> be necessary to be a member of an organization, and membership confers the
> title "engineer", then having that set of qualifications and conduct ought
> to confer the title *with or without* membership in the organization.
> Meanwhile, at least some members of any given organization will usually
> not actually meet the nominal or formalized standard in one way or another.
At the moment those standards do not exist for the majority of software
developers. So it's pretty much a moot point.
If the standards did exist, how would you know that a person who claimed
a title actually deserved it, without having them go through a
certification process?
[ SNIP ]
AHS
Seebs
> At the moment those standards do not exist for the majority of software
> developers. So it's pretty much a moot point.
I am not convinced that they don't; formalization is not existance.
> If the standards did exist, how would you know that a person who claimed
> a title actually deserved it, without having them go through a
> certification process?
How would you know if there WERE a certification process? Answer: You
wouldn't.
It's not as though no one's ever tried it. We have a number of certification
processes. They consistently work, if what you want is to know that someone
once managed to memorize a bunch of stuff for a test. I have seen nothing
to suggest that any other field's "certification processes" are actually
substantially better than this. Certainly, they are extremely popular,
especially among people who have already obtained those certifications.
Arved Sandstrom
> On 2010-02-09, Arved Sandstrom <dce...@hotmail.com> wrote:
>> At the moment those standards do not exist for the majority of software
>> developers. So it's pretty much a moot point.
>
> I am not convinced that they don't; formalization is not existance.
>
>> If the standards did exist, how would you know that a person who claimed
>> a title actually deserved it, without having them go through a
>> certification process?
>
> How would you know if there WERE a certification process? Answer: You
> wouldn't.
How would I, or you, not know? It's not like we are discussing Masonic
rites here.
I myself have chosen not to get any software development certifications,
except for one that I got from the technical campus of Dalhousie
University for a series of software development courses. It's not that I
consider many of the MS and Java etc etc certifications to be
individually useless - many are not - but lacking a larger professional
development framework to plug them into, and because the accountability
of software developers currently is risible, why bother?
> It's not as though no one's ever tried it. We have a number of certification
> processes. They consistently work, if what you want is to know that someone
> once managed to memorize a bunch of stuff for a test. I have seen nothing
> to suggest that any other field's "certification processes" are actually
> substantially better than this.
I can only comment on engineering (I am not one myself but I have a
diploma in engineering, and most of the credits for a baccalaureate in
engineering - I eventually decided to concentrate on a physics degree; I
am also reasonably familiar with how APENS, the Association of
Professional Engineers of Nova Scotia, does these things).
Engineering "certification" processes are considerably better and more
comprehensive than anything that most software developers are ever
exposed to. Starting with education - there's no requirement at all that
software developers have a relevant degree or associate degree, or
indeed any real SD training at all. Try that with prospective
professional engineeers.
It's not just entry-level certification that software developers lack.
It's code of conduct, professional education, duty to the client,
professional discipline and so forth. These are all standards. In order
for software "engineering" to really be engineering it has to adopt
similar standards.
Certainly, they are extremely popular,
> especially among people who have already obtained those certifications.
>
> -s
_What_ are extremely popular? Professional engineering accreditations or
software development certifications? I expect both are.
AHS
debra h
wrote:
> On Fri, 5 Feb 2010 04:23:41 -0800 (PST), Richard Cornford
> <Rich...@litotes.demon.co.uk> wrote, quoted or indirectly quoted
> someone who said :
>
>
>
> >Strange question; the most efficient motivator of professionals is
> >money, and money is very popular.
>
> That may be a motivator for taking a job, but I suspect is fairly far
> down the list for leaving a job.
>
> Leaving motivations might include:
>
> personality conflict
> boredom
> too much pressure
>
> Personally, the opportunity to do something I had never done before
> was always the top priority. Employers usually want people who have
> extensive specific experience.
>
> In hiring, my main interest was loyalty. Employees don't get really
> useful until after the first year. I don't expect them to hit the
> ground running. I anticipate investing considerable effort in training
> them. I looked for reasons why they would likely want to stay.
> --
> Roedy Green Canadian Mind Productshttp://mindprod.com
>
> You can’t have great software without a great team, and most software teams behave like dysfunctional families.
> ~ Jim McCarthy
Mike Duffy
news:4d5qm59hu2crjdppq...@4ax.com:
> Leaving motivations might include:
>
> personality conflict
> boredom
> too much pressure
- Working hours
- Lack of access to training
- Lack of privacy (email snooping, sharing a desk with others.)
And don't forget work-related health problems or an unhealthy work
environment that management refuses to address. (Harassement, A/C
ventilation, lack of ergonomic furniture, employee security etc.)
Death is always the most compelling reason for not continuing to work.
Tom Anderson
> On 2010-02-08, Martin Gregorie <mar...@address-in-sig.invalid> wrote:
>> That's easy: anybody who isn't a member of a recognised engineering
>> society should not be called an engineer and should be laughed out of
>> town if they call themselves one.
>
> This strikes me as the polar opposite of an engineering mindset, which
> would be that a thing is what it is, and isn't what it isn't, regardless
> of any labels.
No, the engineering mindset is that a thing is what it's been validated by
testing to be. If it works but you haven't proven it works, then it
doesn't work. You could see qualifications as being the HR equivalent of
testing.
The minor problem here is that no *software* engineering qualifications
are worth shit, because there isn't really such a thing as software
engineering, but that's a different debate.
tom
--
No hay banda
Martin Gregorie
>
> The minor problem here is that no *software* engineering qualifications
> are worth shit, because there isn't really such a thing as software
> engineering, but that's a different debate.
>
...and an MBCS is worth remarkably little because bad apples never seem
to be thrown out.
John Koy
[...]
> Engineering "certification" processes are considerably better and more
> comprehensive than anything that most software developers are ever
> exposed to. Starting with education - there's no requirement at all that
> software developers have a relevant degree or associate degree, or
> indeed any real SD training at all. Try that with prospective
> professional engineeers.
>
> It's not just entry-level certification that software developers lack.
> It's code of conduct, professional education, duty to the client,
> professional discipline and so forth. These are all standards. In order
> for software "engineering" to really be engineering it has to adopt
> similar standards.
>
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.
Seebs
> On Mon, 8 Feb 2010, Seebs wrote:
>> This strikes me as the polar opposite of an engineering mindset, which
>> would be that a thing is what it is, and isn't what it isn't, regardless
>> of any labels.
> No, the engineering mindset is that a thing is what it's been validated by
> testing to be. If it works but you haven't proven it works, then it
> doesn't work.
Proof and testing are not the same thing. Ideally, you'd both prove and test
that something works.
> You could see qualifications as being the HR equivalent of
> testing.
I'd see them as the HR equivalent of abstract proof without any testing.
You test an engineer by having the engineer build stuff and then see whether
it works (both proof and test). Merely knowing that the engineer has
"qualifications" is like knowing that, on paper, a design "works".
> The minor problem here is that no *software* engineering qualifications
> are worth shit, because there isn't really such a thing as software
> engineering, but that's a different debate.
I don't buy it. Software engineering isn't the exact same kind of thing
as structural engineering is, or the exact same kind of thing as electrical
engineering is, but then, those aren't quite exactly the same kind of thing
either. There is an overall pattern to the things that get labeled
engineering, and it doesn't require that every instance of it have precisely
the same traits in every last respect.
MarkusSchaber
On 10 Feb., 00:28, Seebs <usenet-nos...@seebs.net> wrote:
> I don't buy it. Software engineering isn't the exact same kind of thing
> as structural engineering is, or the exact same kind of thing as electrical
> engineering is, but then, those aren't quite exactly the same kind of thing
> either.
I personally think that the main difference between "Software
Development" and classical "engineering" is the level of abstraction.
Software development tends to have far more levels of abstraction, and
even their lowest levels of abstraction build on top of those levels
provided by the electrotechnical engineers.
http://www.artima.com/weblogs/viewpost.jsp?thread=255898 is also a
good reading on why software development is neither engineering nor
mathematics.
Markus
Seebs
> I personally think that the main difference between "Software
> Development" and classical "engineering" is the level of abstraction.
> Software development tends to have far more levels of abstraction, and
> even their lowest levels of abstraction build on top of those levels
> provided by the electrotechnical engineers.
This is true. However, I don't think that makes it "not really engineering",
any more than using a shovel means you're not *really* digging, just using
a tool provided by someone who makes digging implements.
Of course... It would make sense for me to think that way. Since I do
software development, and that means I spend a lot of time working with
many levels of abstraction, I tend to think that abstractions built on
other things are not all that different from the things they're built on.
Malcolm McLean
> 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.
>
exclusions are necessary. They would be commercial suicide in any
other field. That doesn't mean there is no such thing as software
engineering, only that it is new and undeveloped. Boilers used to
regularly explode at the beginning of the industrial revolution, now
such accidents are almost unheard of.
Arved Sandstrom
It's not a question of bug _free_ software. There aren't any other
fields I can think of where it's possible to get away with no liability
simply by claiming that it's impossible to achieve perfection.
It's also not entirely an issue of software "engineering" being an
infant field. The fact is that there exist adequate processes that apply
to every stage of the software lifecycle, and most software shops only
pay lip service to some or all of them. Doing proper requirements
analysis is not "undeveloped". Doing proper design is not "undeveloped".
Doing proper implementation in your languages of choice is not
"undeveloped". And doing proper testing and QA/GC is not "undeveloped".
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. That whole
mindset is not a problem that's going to be fixed by pushing for a
software engineering profession, because the desire for such a
professional status follows from a mindset that already follows the
basic principles in the first place.
We need to get pushed from the outside, by purchasers of our software.
Unfortunately that hasn't happened.
AHS
Michael Foukarakis
wrote:
> On Feb 10, 1:02 am, John Koy <John....@example.com> 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.
give certain guarantees. When those are failed to be met, (s)he is
held liable. Maybe it's about time some "software engineers" were held
liable for their unreliable code in the same way.
> They would be commercial suicide in any
> other field.
I don't see structural engineering or computer hardware engineering
going anywhere anytime soon..
> That doesn't mean there is no such thing as software
> engineering, only that it is new and undeveloped. Boilers used to
> regularly explode at the beginning of the industrial revolution, now
> such accidents are almost unheard of.
That's absolutely right. But we can't sit and wait for software
development to be refined on its own, we should probably do something
about it. Collectively or whatnot.
Malcolm McLean
>
> 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.
>
> Unfortunately that hasn't happened.
>
available that could ensure bug-free software, at reasonable cost and
time, they they would have been adopted. Except in a few areas
customers would soon shy away from 'no warrantry including the implied
warrantry of suitability for any particular purpose' products.
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.
John Koy
> Malcolm McLean wrote:
>> On Feb 10, 1:02 am, John Koy <John....@example.com> 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. They would be commercial suicide in any
>> other field. That doesn't mean there is no such thing as software
>> engineering, only that it is new and undeveloped. Boilers used to
>> regularly explode at the beginning of the industrial revolution, now
>> such accidents are almost unheard of.
>
> It's not a question of bug _free_ software. There aren't any other
> fields I can think of where it's possible to get away with no liability
> simply by claiming that it's impossible to achieve perfection.
Exactly. Engineering is about measurable outcomes, quantification.
What's the equivalent of "this building can withstand a quake of
magnitude 7.5 for 30 seconds" in software? Can any of us state "this
software will stand all virus attacks for 12 months" or "this software
will not crash for 2 years, and if it does your loss won't exceed 20% of
all digital assets managed by it" ?
We can't even guarantee that it won't crash tomorrow, why? Well, for me,
because the underlying platform (OS/JRE/CLR/VM/etc) does not give me any
guarantees. I cannot build any engineering product on top of that, no
matter what process I employ.
Engineering is not about "during", it's about "after": accountability,
liability, warranties, hence insurability. And these shape how the
process of "during" must be. Without them, it's just some monkey
business, hence SD.
Registered User
<dce...@hotmail.com> wrote:
>
>It's also not entirely an issue of software "engineering" being an
>infant field. The fact is that there exist adequate processes that apply
>to every stage of the software lifecycle, and most software shops only
>pay lip service to some or all of them. Doing proper requirements
>analysis is not "undeveloped". Doing proper design is not "undeveloped".
>Doing proper implementation in your languages of choice is not
>"undeveloped". And doing proper testing and QA/GC is not "undeveloped".
>
>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. That whole
>mindset is not a problem that's going to be fixed by pushing for a
>software engineering profession, because the desire for such a
>professional status follows from a mindset that already follows the
>basic principles in the first place.
>
>We need to get pushed from the outside, by purchasers of our software.
>Unfortunately that hasn't happened.
>
All good points but the 'we' gives me trouble. Weak project management
is the real 'we'.
<rant>
The SDLC should not be determined by the calendar, don't ask how long
'it' will take after promising a due date plucked out of thin air.
Images of what a web app should look like doesn't qualify as a design.
A design document shouldn't contain contradictory requirements and
business rules shouldn't describe how the UI is to function.
Re-usability doesn't end at the UI. Security shouldn't be an
afterthought. Requirements shouldn't disappear solely because the
completion date is nearing, maybe they shouldn't have been
requirements initially. Success shouldn't be based upon meeting an
arbitrary date. Define "forward compatibility" before making it a
requirement. Understand the differences between requirements, features
and chrome. ... KISS
</rant>
The are many reasons why over-promised and under-delivered appears to
be the de facto standard. Rather than continue to rant, let me point
to this article.
http://www.infoworld.com/d/adventures-in-it/run-it-business-why-thats-train-wreck-waiting-happen-477?page=0,0
or
http://tinyurl.com/it-train-wreck
regards
A.G.
Wojtek
> And doing proper testing and QA/GC is not "undeveloped".
This is the equivalent of building a bridge, then driving over it. If
it does not collapse, then proper engineering was used.
If it does collapses, well then we just re-build it and try again.
--
Wojtek :-)
MarkusSchaber
On 10 Feb., 12:32, John Koy <John....@example.com> wrote:
> We can't even guarantee that it won't crash tomorrow, why? Well, for me,
> because the underlying platform (OS/JRE/CLR/VM/etc) does not give me any
> guarantees. I cannot build any engineering product on top of that, no
> matter what process I employ.
And that is the problem with the abstraction levels I mentioned. Even
the OS cannot guarantee anything because our mainstream hardware is
extremely underspecified (e. G. try to get any time guarantees for
hard disk access) and does not guarantee for anything (see the long
errata list of current CPUs, or the statistics about RAM error rates
due to cosmic rays.
Seebs
> Nobody knows how to build earthquake-immune buildings, yet engineers
> give certain guarantees. When those are failed to be met, (s)he is
> held liable. Maybe it's about time some "software engineers" were held
> liable for their unreliable code in the same way.
Why?
Do you have any evidence to suggest that this kind of liability is actually
reasonable, justified, and/or necessary?
> That's absolutely right. But we can't sit and wait for software
> development to be refined on its own, we should probably do something
> about it. Collectively or whatnot.
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.
Seebs
> the OS cannot guarantee anything because our mainstream hardware is
> extremely underspecified (e. G. try to get any time guarantees for
> hard disk access) and does not guarantee for anything (see the long
> errata list of current CPUs, or the statistics about RAM error rates
> due to cosmic rays.
Yeah, and if all you have is improvised materials, you can't be sure the
things you build will work. That doesn't mean you're not an engineer. The
sign of being not-an-engineer would be promising that they'll work anyway.
The job of the engineer is to know enough to build something as reliably
as possible with the available tools, and tell you how reliable that is.
Usually, with software, the answer is "not all that reliable". But since
software engineers know that, and tell people that, and give clear evidence
that they've carefully analyzed the components to be able to tell you that,
it sounds to me like they're doing exactly what engineers ought to do.
I think the obsession with whether or not there is liability misses the point;
that's a social convention adopted for fields where the tools are much
simpler, it's nothing to do with the substance of what engineers are doing.
Lew
>> 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.
Malcolm McLean wrote:
> Software management is not so stupid. If adequate procedures were
> available that could ensure bug-free software, at reasonable cost and
> time, they they would have been adopted. Except in a few areas
Bullshit.
Management doesn't adopt effective practices for a variety of reasons, but the
fact is that far too many projects are managed in fashions contrary to best
practices. It's a combination of application of an inappropriate management
paradigm (factory work vs. talent work), ignorance or disbelief of the
fundamentals, mistrust of the commitment and understanding of the developers,
and a desire to keep the process inefficient in order to collect more money.
The observable fact is that software projects are managed as though management
were stupid. That's why half to two-thirds (depending on whose figures you go
by) of all major software projects never go into production, and so many that
do have major, preventable bugs.
> customers would soon shy away from 'no warrantry including the implied
> warrantry of suitability for any particular purpose' products.
Adequate procedures are available, or haven't you been studying the subject?
> 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.
Again, not true. Iterative development alone greatly increases productivity
and quality. Add in other elements of agile programming, or whatever the
rubric is for effective practices these days, and you asymptotically approach
perfection.
The field of software project management is well studied and well documented.
Effective techniques are known and published. And have been for decades.
They simply are not followed.
--
Lew
Pete Becker
> The job of the engineer is to know enough to build something as reliably
> as possible with the available tools,
And within the available budget.
and tell you how reliable that is.
Anyone can build a bridge that stands up. It takes an engineer to build
on that barely stands up.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
Andy Champ
<snip>
> Exactly. Engineering is about measurable outcomes, quantification.
> What's the equivalent of "this building can withstand a quake of
> magnitude 7.5 for 30 seconds" in software? Can any of us state "this
> software will stand all virus attacks for 12 months" or "this software
> will not crash for 2 years, and if it does your loss won't exceed 20% of
> all digital assets managed by it" ?
To some extent that's an unfair comparison. 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.
And "your loss won't exceed 20% of all digital assets"? That's a very
soft target. I have put together systems designed to safeguard data,
and have lost no data, and would not expect to lose data. It's called
redundancy. Software failures really do not wipe a fifth of the stored
data - we're _much_ better than that.
The residents of Haiti might have a few words about buildings designed
to withstand 7.5 magnitude earthquakes. And after all, it was due:
http://www.sciencedaily.com/releases/2005/02/050205102502.htm
Andy
Volker Borchert
> Seebs wrote:
> > The job of the engineer is to know enough to build something as reliably
> > as possible with the available tools,
>
> And within the available budget.
>
> and tell you how reliable that is.
>
> Anyone can build a bridge that stands up. It takes an engineer to build
> on that barely stands up.
What about Galloping Gertie?
--
"I'm a doctor, not a mechanic." Dr Leonard McCoy <mc...@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <v_bor...@despammed.com>
James Kanze
But that's really only the case for shrink-wrapped software (and
presumably, it doesn't exclude your legal guarantees). Most of
the projects I've worked on did have guarantees, and contractual
penalties for downtime.
--
James Kanze
James Kanze
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).
> They would be commercial suicide in any other field. That
> doesn't mean there is no such thing as software engineering,
> only that it is new and undeveloped. Boilers used to regularly
> explode at the beginning of the industrial revolution, now
> such accidents are almost unheard of.
Well written software fails a lot less frequently than
automobile brakes.
--
James Kanze
James Kanze
wrote:
> On Feb 10, 12:29 pm, Arved Sandstrom <dces...@hotmail.com> 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. If adequate procedures
> were available that could ensure bug-free software, at
> reasonable cost and time, they they would have been adopted.
Guaranteed error-free doesn't exist in any domain. It's not too
difficult to achieve error rates of less than one error per 100
KLoc, however, and at least one shop does less than one error
per million lines of code. Curiously enough, achieving one
error per 100 KLoc typical reduces your development costs. But
for whatever reasons, in many companies, this goes
unnoticed---in the end, if you're selling shrink wrapped
software, development costs are more or less negligible,
compared to marketing costs, so it doesn't matter if you spend a
bit more.
> Except in a few areas customers would soon shy away from 'no
> warrantry including the implied warrantry of suitability for
> any particular purpose' products.
Legally, of course, you have certain rights, regardless of what
the "warrenty" says. It's just that as far as I know, no one
has attempted to enforce them for software.
> 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.
Less that one error per million lines of code is achievable.
And I've worked on projects where we had less than one error per
100 KLoc (going into integration).
--
James Kanze
James Kanze
> Arved Sandstrom 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.
> Malcolm McLean wrote:
> > Software management is not so stupid. If adequate procedures
> > were available that could ensure bug-free software, at
> > reasonable cost and time, they they would have been adopted.
> > Except in a few areas
> Bullshit.
> Management doesn't adopt effective practices for a variety of
> reasons, but the fact is that far too many projects are
> managed in fashions contrary to best practices. It's a
> combination of application of an inappropriate management
> paradigm (factory work vs. talent work), ignorance or
> disbelief of the fundamentals, mistrust of the commitment and
> understanding of the developers, and a desire to keep the
> process inefficient in order to collect more money.
I suspect that it's often a case of management not being able to
be everywhere, and the fact that marketing issues are far more
important than saving a bit of money (while simultaneously
improving quality) in development.
> The observable fact is that software projects are managed as
> though management were stupid. That's why half to two-thirds
> (depending on whose figures you go by) of all major software
> projects never go into production, and so many that do have
> major, preventable bugs.
I've often wondered where such statistics come from. Over the
last twenty years, only one project I've worked on failed to go
into production, and none of the others had major, preventable
bugs---in at least one, the most serious bug that was found was
a spelling error in a log message, and in one other case, no
errors were found after delivery (but that was a very small
project).
> > customers would soon shy away from 'no warrantry including
> > the implied warrantry of suitability for any particular
> > purpose' products.
> Adequate procedures are available, or haven't you been
> studying the subject?
> > 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.
> Again, not true. Iterative development alone greatly
> increases productivity and quality. Add in other elements of
> agile programming, or whatever the rubric is for effective
> practices these days, and you asymptotically approach
> perfection.
From what I've seen, "agile" programming hasn't really changed
much. In fact, it's often been just a relabeling of the same
old procedures. (That's a common problem with "in"
labels---before agile programming, a lot of projects became "OO"
overnight. With no change in procedures.)
> The field of software project management is well studied and
> well documented. Effective techniques are known and
> published. And have been for decades. They simply are not
> followed.
Except where they are. I was a contractor for the last 25 or 30
years, and most of the places I worked did you more or less
effective techniques.
--
James Kanze
James Kanze
> Arved Sandstrom wrote:
> > Malcolm McLean wrote:
> >> On Feb 10, 1:02 am, John Koy <John....@example.com> 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. They would be
> >> commercial suicide in any other field. That doesn't mean
> >> there is no such thing as software engineering, only that
> >> it is new and undeveloped. Boilers used to regularly
> >> explode at the beginning of the industrial revolution, now
> >> such accidents are almost unheard of.
> > It's not a question of bug _free_ software. There aren't any
> > other fields I can think of where it's possible to get away
> > with no liability simply by claiming that it's impossible to
> > achieve perfection.
> Exactly. Engineering is about measurable outcomes,
> quantification. What's the equivalent of "this building can
> withstand a quake of magnitude 7.5 for 30 seconds" in
> software?
A contractual indemnity for each second of downtime? (Most of
the projects I've worked on have had such clauses in their
contracts.)
> Can any of us state "this software will stand all virus
> attacks for 12 months" or "this software will not crash for 2
> years, and if it does your loss won't exceed 20% of all
> digital assets managed by it" ?
Most of the projects I've worked on have had clauses to the
effect that "we will pay you x Euros per minute downtime". It
seems to be a more or less standard clause.
> We can't even guarantee that it won't crash tomorrow, why?
> Well, for me, because the underlying platform
> (OS/JRE/CLR/VM/etc) does not give me any guarantees. I cannot
> build any engineering product on top of that, no matter what
> process I employ.
True, the underlying platform is always a risk. But then, you
don't have to push it, and you're normally not the first user of
it, and you've validated it, so you have some confidence that it
won't crash for what you're using it for.
--
James Kanze
James Kanze
> Seebs wrote:
> > The job of the engineer is to know enough to build something as reliably
> > as possible with the available tools,
> And within the available budget.
> and tell you how reliable that is.
> Anyone can build a bridge that stands up. It takes an engineer
> to build on that barely stands up.
Or to tell you exactly what it will stand up to, or how much it
will cost before you start building it.
And of course, that's exactly what we do every day when we
develop software. Customers won't give us the contract unless
we can provide concrete guarantees with regards to downtime,
etc., and unless we can specify a guaranteed fixed cost in
advance.
--
James Kanze
James Kanze
:-)
That's the way things were in software thirty or fourty years
ago. But it's true that some people have relabeled the
procedure, and are trying to sell it today. (See TDD.)
--
James Kanze
James Kanze
wrote:
> On Feb 10, 12:03 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:> On Feb 10, 1:02 am, John Koy <John....@example.com>
> 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.
> Nobody knows how to build earthquake-immune buildings, yet
> engineers give certain guarantees. When those are failed to be
> met, (s)he is held liable. Maybe it's about time some
> "software engineers" were held liable for their unreliable
> code in the same way.
They are. That's why independent contractors have liability
insurance.
--
James Kanze
James Kanze
> On 2010-02-10, Michael Foukarakis <electricde...@gmail.com> wrote:
> > Nobody knows how to build earthquake-immune buildings, yet
> > engineers give certain guarantees. When those are failed to
> > be met, (s)he is held liable. Maybe it's about time some
> > "software engineers" were held liable for their unreliable
> > code in the same way.
> Why?
> Do you have any evidence to suggest that this kind of
> liability is actually reasonable, justified, and/or necessary?
Reasonable, justified or necessary, I don't know. But it's a
fact of life. If you deliver software, and it fails, you're
liable for it. Most of the time, the liability is spelled out
in the contract, but that still doesn't exclude any legal
guarantees the buyer may have.
--
James Kanze
Arved Sandstrom
Car and computer and TV manufacturers don't guarantee that their
products are 100% absolutely going to work either - why should we have
to? The point being that with existing and understood software
development methodologies, if those are assiduously applied then we can
safely state that for a given population of application deployments that
such and such a percentage of them will fail badly, another fraction
will encounter serious problems that require dedicated support under
warranty, another fraction will encounter minor problems, and so forth.
It's precisely this kind of statistical knowledge that lets you provide
consumers with certain protections - warranties, support offers, and so
forth. We're already doing it with major applications - we could do this
with the majority if we just bothered to write quality software in the
first place.
Seriously, though, why the insistence on perfection? We don't get
perfection from engineers (or other professionals) either, nor from
manufacturers of tangible goods and structures. Transportation
infrastructure crumbles before its time. We are resigned to consumer
goods that must be regarded as disposable (and not all are _designed_ to
be disposable). We accept that not so long after buying a new car that
we will be regularly repairing it. Sick buildings are common. Tens of
thousands of surgical mistakes are made every year just in North
America. Manufacturers of electronics and electrical equipment make a
mint off people who can't be bothered to return broken stuff, and buy
new replacements instead.
A software engineering profession would not require perfect software any
more than traditional engineers are expected to design perfect equipment
or machinery or structures. All I'm saying is that we can do
considerably better, and we can do that to the extent that we can
provide the same protection to consumers for software as we already for
cars or vacuum cleaners.
AHS
Arved Sandstrom
> On 2010-02-10, Michael Foukarakis <electr...@gmail.com> wrote:
>> Nobody knows how to build earthquake-immune buildings, yet engineers
>> give certain guarantees. When those are failed to be met, (s)he is
>> held liable. Maybe it's about time some "software engineers" were held
>> liable for their unreliable code in the same way.
>
> Why?
>
> Do you have any evidence to suggest that this kind of liability is actually
> reasonable, justified, and/or necessary?
>
>> That's absolutely right. But we can't sit and wait for software
>> development to be refined on its own, we should probably do something
>> about it. Collectively or whatnot.
>
> 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.
AHS
Brian
> On Feb 10, 10:03 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
>
> > On Feb 10, 1:02 am, John Koy <John....@example.com> 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
http://webEbenezer.net
(651) 251-9384