[prog] State of software engineering profession

Mary mary-linuxchix at puzzling.org
Mon Apr 14 23:25:47 EST 2003


On Mon, Apr 14, 2003, Jimen Ching wrote:
> I'm not sure what you mean.  Can you elaborate?  Do you mean I should
> give my qualifications?

In the sense that you should discuss your qualifications to talk about
this, yes. That may not mean academic qualifications (although if you
did a PhD thesis on software engineering techniques, that would be an
example of a qualification)

Let's rephrase. Discuss your experiences.

What bad experiences have you had? How long have you been in the
industry? What sort of design-implementation cycles have you been part
of? What was wrong with them? Why are you saying this? Have you had a
chance to lead a team using your ideas, or anyone else's for that
matter? How did it turn out? Who have you talked to about this? What did
they say?

So far, most of the participants in the conversation broadly agree with
you, and you are taking our lack of enthusiasm to be dissent rather than
a "yes... and?" response.

Listen: we basically agree with you. Software engineering is an
imprecise process that often results in poor products and unsatisfied
customers, and sometimes in downright dangerous products.

So, move this conversation to the next stage. What are your proposals?
Where have you tried them? If you haven't, why will they work when
others have failed? How do they compare with existing best practice? How
do they fit in with Free Software development models?

Give us something concrete PLEASE.

[And others are welcome to jump in with their own ideas here - let's
push this along.]

STOP assuming we disagree with your basic premise. That assumption is
simply wrong, and it's making for a very boring and long-winded thread
when it has the potential to be the most interesting thread on here, and
one that LinuxChix has seldom seen.

> To avoid any confusion.  Let me elaborate what I mean.  Because of
> this 'show us the code' mentality, the programmer is implying that it
> is ok to skip the design phase.  As a result of this lack of planning,
> defects are often introduced.  But as long as the 'feature' is added,
> that's ok.  This is the 'state of our profession' that I was talking
> about.

You don't seem to respond well to analogies, but I'll try and explain
what I've been doing. I'm *not* talking about the industry at all. I'm
not engaging with your argument. I am making a meta-argument - I am
critquing the *type* of argument you are making.

As this stage, you've made the equivalent of a feature proposal. "I want
software engineering to be better." That's nice, but where is the
"design" or the "code" - that is either specific testable ideas of yours
to make things better? You have not yet given us any ideas to test. You
have simply made a point we basically agree with, with some quibbles,
and you've then somehow come to the conclusion that you're a software
missionary in a field of heathens.

Despite your statements to the contrary, everyone here wants software
engineering to be better. There's no need to keep drumming it into us.
You need to give us more specific ideas, facts, procedures, statistics,
anecdotes, *something conrete*, otherwise this entire thread will
continue to be:

Jimen: "Software engineeing should be better."

Others: "Yes. How?"

Jimen: "Your attitude is part of the problem. Software engineering
should be better."

Others: "Yes. How?"

Jimen: "Your attitude is part of the problem. Software engineering
should be better."

Others: "We absolutely agree. How?"

Jimen: "Your attitude is part of the problem. Software engineering
should be better."

ad infinitum.

-Mary


More information about the Programming mailing list