Motivation of software professionals

[Arved Sandstrom]

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]

[...]

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.)

 

[Phil Carmody]

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

 

[Seebs]

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.

-s

 

[Arved Sandstrom]

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.

-s

 

[Arved Sandstrom]

I am not convinced that they don't; formalization is not existance.


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]

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

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.

 

[Mike Duffy]

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.

 

[MarkusSchaber]

Hi,

Death is always the most compelling reason for not continuing to work.

May I consider this the "Quote of the day"[tm]?

 

[Tom Anderson]

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

 

[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]

Arved Sandstrom wrote:
[...]

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]

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.

-s

 

[Fred Saxonberg]

Arved Sandstrom wrote:
[...]

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.

As it turns out there have been attempts at both licensing of software
engineers and a code of conduct.

The ACM (Association for Computing Machinery) has developed a code of
conduct that can be found at:
"http://www.acm.org/about/code-of-ethics".

The state of Texas briefly has a engineering license for "Software
Engineers". I think it was dropped because there was little agreement on
the core body of knowledge required for software engineers.

Both the IEEE software society and the ACM have and continue to address
these issuse. Unforetunately most computer programmers are not members
of either organization.

Fred Saxonberg
Memeber of the ACM since 1969

 

[MarkusSchaber]

Hi,

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.

-s

 

[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.

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.

 

[Arved Sandstrom]

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.

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]

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 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.