I've been seeing discussions here and elsewhere about computer science 
programs that don't teach software engineering.  Software engineering 
clearly has a practical role since people are writing software all over 
the place.  But how does computer science fit into it?  Is that one of 
those things whose primary product is scholarly articles, or does it do 
much to inform the typical maker of software?  Do programmers find 
themselves well served by their CSCI degree, or do they tend to have to 
learn a lot of stuff that just wasn't taught in school?


-- 
"Is that plutonium on your gums?"
"Shut up and kiss me!"
  -- Marge and Homer Simpson

Gregory L. Hansen wrote:
> I've been seeing discussions here and elsewhere about computer science 
> programs that don't teach software engineering.  Software engineering 
> clearly has a practical role since people are writing software all over 
> the place.  But how does computer science fit into it?  Is that one of 
> those things whose primary product is scholarly articles, or does it do 
> much to inform the typical maker of software?  Do programmers find 
> themselves well served by their CSCI degree, or do they tend to have to 
> learn a lot of stuff that just wasn't taught in school?

Computer science (as it's taught and researched in academia) has 
almost nothing to do with the development of software solutions.  CS 
focuses on individual computational techniques, but does not integrate 
these into a whole nor does it deal in the pragmatics of using 
software to solve user needs.  CS curricula use software to solve 
homework problems, not user problems.

This is partly because almost all professors have never been in the 
trenches, producing code under a deadline, with a customer 1) who 
doesn't know what's possible or what is needed, 2) who needs the 
software now, 3) who wants to pay as little as possible for it. 
Making architectural tradeoffs under such circumstances is an entirely 
different enterprise from assessing an algorithm's asymptotic 
complexity.  The latter is still valuable but the former is essential: 
it's the life blood of business.  But on the radar screen of CS 
academics, the needs of business or the user don't rate even a tiny 
dot.  That's why courses in software engineering, application domains, 
and "designing for the user" are rare as hen's teeth in CS.

IMHO, CS is good preparation for:
- teaching CS
- advancing our understanding of the principles of computing
- speeding up software, networks, or microarchitecture
- building new software tools (compilers, O/Ses, databases, etc)
- implementing difficult software components (drivers, kernels, HPC,
   database engines, compilers, network stacks, etc)

IMHO, CS is poor preparation for:
- developing software in teams, on time, that works
- analyzing the need for a given software solution, designing the
   software, testing it, or learning from your mistakes and building
   better software in the future
- managing the lifecycle of a program (including documentation)
- understanding how software is used (by business or the individual)
- engineering a software solution as a collection of cost tradeoffs
- debugging existing code and reducing bugs in future code
- understanding the user's problem space or mapping software to the
   problem space

I've always been amazed that NOBODY in academia has laid claim to the 
agenda of experimental software engineering.  There is a CRYING need 
to assess the relative success of different programming models, much 
less quantitatively assessing analysis models, design processes, 
implementation tradeoffs, testing practices, etc.  Oddly, NOBODY in 
academia does this sort of thing.  Even when a department comes along 
that calls itself "software engineering" purportedly to undertake 
these much needed investigations, instead they seem fascinated with 
the theory of software development, as an abstract model of how 
software MIGHT be built, but not the concrete evaluation of what works 
and what doesn't.

I understand that like experimental/quantitative economics, taking a 
practical approach to software is a lot more work than is proposing 
philosophy or theory.  But practice is a hell of a lot more useful too.

     Randy

-- 
Randy Crawford   http://www.ruf.rice.edu/~rand   rand AT rice DOT edu

Gregory L. Hansen wrote:
> I've been seeing discussions here and elsewhere about computer science
> programs that don't teach software engineering.  Software engineering
> clearly has a practical role since people are writing software all over
> the place.  But how does computer science fit into it?  Is that one of
> those things whose primary product is scholarly articles, or does it do
> much to inform the typical maker of software?  Do programmers find
> themselves well served by their CSCI degree, or do they tend to have to
> learn a lot of stuff that just wasn't taught in school?

Considered as "success in implementing software", "software
engineering" has little to say because in fact there is little success
(with an 80% failure rate according to some sources).

If the SE student desires his personal success he may as well learn
that in a laissez-faire economy nobody has any interest in teaching him
how to steal their ricebowl and that in this regard much (not all) of
software engineering is like learning options, puts and calls. The
personally successful are too busy making money.

Good programmers on the other hand are precisely who use computer
science. Period. They use it to the point of resistance to that part of
"software engineering" which is constituted in learning subservience.
>
>
> --
> "Is that plutonium on your gums?"
> "Shut up and kiss me!"
>   -- Marge and Homer Simpson

Randy wrote:
> Gregory L. Hansen wrote:
> > I've been seeing discussions here and elsewhere about computer science
> > programs that don't teach software engineering.  Software engineering
> > clearly has a practical role since people are writing software all over
> > the place.  But how does computer science fit into it?  Is that one of
> > those things whose primary product is scholarly articles, or does it do
> > much to inform the typical maker of software?  Do programmers find
> > themselves well served by their CSCI degree, or do they tend to have to
> > learn a lot of stuff that just wasn't taught in school?
>
> Computer science (as it's taught and researched in academia) has
> almost nothing to do with the development of software solutions.  CS

This is simply incorrect. Most workable solutions are based on some
form of cs. It is characteristic of unworkable solutions that they are
not.

> focuses on individual computational techniques, but does not integrate
> these into a whole nor does it deal in the pragmatics of using
> software to solve user needs.  CS curricula use software to solve
> homework problems, not user problems.

At Princeton this "homework" at senior level consists of developing a
complete hardware and software system. At DeVry at the other end of the
scale it consists in setting up a complete network.

Universities have long emphasized integration and much of cs is about
that form of "integration" that results naturally from factoring and
analysis.

The missing element in the university is the cash nexus between the
developer and employer and this changes everything into a struggle, not
to develop the best system, but to develop the system with the least
amount of intellectual effort (thereby favoring the developer) in the
shortest amount of time (in the company's interest).

>
> This is partly because almost all professors have never been in the
> trenches, producing code under a deadline, with a customer 1) who

Completely false. At the high end Brian Kernighan started out at Bell
Labs and many CS profs have formed their own business. Likewise at the
low end.

It may be a comforting myth to believe that by definition a college
professor in an APPLIED discipline doesn't know about rough and tough
realities but the problem is you go to the professor of an APPLIED
discipline to learn how to APPLY theory to practice.

So what you end up claiming is that our society subsidizes a class of
professors who don't know their ass from a hole in the ground despite
the fact that as in the case of Kernighan they started out in the
corporation and toplevel cs profs have long been in demand at levels
above "programming".

I find this all rather hard to believe. Instead I think what happens is
that anhedonic and alienated students flock into CS programs and fail
to master their trade.

Nearly all of CS is about making problems including "software
engineering" intellectually manageable. Your claim is that it has
failed yet Open Source shows you're wrong because it characteristically
uses a bit "more" CS (Linux, for example, developed by a CS grad
student, not a "software engineer").

Basically, what the computer scientist must master in 'software
engineering' is a form of personnel management and a *bricolage* of
negative capabilities which cause actual developers to cut corners and
put in extra hours as needed.

This cannot be "taught".

> doesn't know what's possible or what is needed, 2) who needs the
> software now, 3) who wants to pay as little as possible for it.

Well, human beings as such already know how to extract surplus value
from each other. If the university got into the business of teaching
how to pimp other people who want to pay you as little as possible,
then for it to succeed, simple microeconomic reasoning would tell us
that nobody would make any money. All actors would have full
information and the game would be zero sum.

> Making architectural tradeoffs under such circumstances is an entirely
> different enterprise from assessing an algorithm's asymptotic
> complexity.  The latter is still valuable but the former is essential:
> it's the life blood of business.  But on the radar screen of CS
> academics, the needs of business or the user don't rate even a tiny
> dot.  That's why courses in software engineering, application domains,
> and "designing for the user" are rare as hen's teeth in CS.

This can only be taught in the vulgar and stupid fashion of Donald
Trump in the Apprentice.

The Donald sends two teams of people out on a mission and then compares
their net profit, in the typical show. He then "explains" why the
losing team failed by criticising post-facto various choices they made.
In a uniquely vulgar "money talks" fashion he makes the losers feel
small because, he typically says, they were not exercising their common
sense.

But what has actually happened in the "reality" of this "reality"
program is that the loser team has tried to "sell", in one or two days,
a critical mass of randomly selected people, where mathematically
speaking, the size of the set is so small that NO generalizations can
be rationally made!

Software engineering has to "teach" in this irresponsible manner, by
means of the case study.

The problem with the case study is that it is post facto, and NO
generalizations can be scientifically made from it, because its base
entities are chaotic and complex systems (people and companies).

The State of Virginia wasted five years and millions of dollars trying
to use a Peoplesoft client-server system for human resources, only to
scrap it and write the needed functionality in five months using Java.

Nothing can be really learned from this narrative, for the failure may
have taught Peoplesoft to pay more attention to nonprofits in such a
way that it does a markedly better job in meeting their needs. Nor does
it mean that Java is intrinsically faster.

Other than the case study, what does software engineering provide?
Nothing of substance beyond operations research and computer science.

>
> IMHO, CS is good preparation for:
> - teaching CS
> - advancing our understanding of the principles of computing
> - speeding up software, networks, or microarchitecture
> - building new software tools (compilers, O/Ses, databases, etc)
> - implementing difficult software components (drivers, kernels, HPC,
>    database engines, compilers, network stacks, etc)
>
> IMHO, CS is poor preparation for:
> - developing software in teams, on time, that works

The vulgar meaning of "works" in software is "gawrsh, my program
consumes resources without crashing, and the user is all happy". The
problem (as seen in the manufacture of reasons for the Iraq war) the
user may be happy because the answers provided by the software meet his
agenda.

Of course, computer science has nothing to contribute to this form of
grab-ass.

> - analyzing the need for a given software solution, designing the
>    software, testing it, or learning from your mistakes and building
>    better software in the future

"Learning from your mistakes and building better software in the
future" isn't taught, or teachable.

If it is a form of office groveling, universities shouldn't teach
people to grovel. My own university's motto was Education for Freedom.

If on the other hand it is the humility of the learned man who (without
some corporation needing to tell him) is always learning, because like
Master Kong (Confucius) he asks

   "Is it not a pleasure, having learned something, to try it out
    at due intervals? Is it not a joy to have friends come from afar?
    Is it not gentlemanly not to take offence when others fail to
    appreciate your abilities?"

then philosophy, not software engineering, teaches this.

As to "analyzing the need". Guess what? At the top level (hey, do we
need this enterprise requirements planning system, or what?) computer
science AND software engineering are silent. They can advise the CEO as
to what it will cost but the decision is that of the CEO and it's a
policy decision.

I realize, however, that a favorite form of American corporate grab-ass
is to say of an enterprise system that "we didn't want it", but this
grab-ass is basically that American CEO gesture of denying
responsibility for what happened on his watch as seen at Enron.

I am not denying that the CEO has a real problem. This is that the
"materiality", the hardware and software, of a data system is by
definition always surplus to his business.

Indeed it has been shown that "enterprise" systems seldom make
companies a dime. Instead they cause a qualitative transformation that
allows the first adopter of an enterprise model to create a market as
in the case where Barnes and Noble, Amazon and Borders use modern data
bases to do business in a new way.

The operations research and "tradeoffs" of software engineering are
useless in counseling companies how to take a leap into a void.

> - managing the lifecycle of a program (including documentation)

Here it IS true that compsci programs do a poor job in teaching
students how to write.

> - understanding how software is used (by business or the individual)
> - engineering a software solution as a collection of cost tradeoffs
> - debugging existing code and reducing bugs in future code
> - understanding the user's problem space or mapping software to the
>    problem space
>
> I've always been amazed that NOBODY in academia has laid claim to the
> agenda of experimental software engineering.  There is a CRYING need
> to assess the relative success of different programming models, much
> less quantitatively assessing analysis models, design processes,
> implementation tradeoffs, testing practices, etc.  Oddly, NOBODY in
> academia does this sort of thing.  Even when a department comes along
> that calls itself "software engineering" purportedly to undertake
> these much needed investigations, instead they seem fascinated with
> the theory of software development, as an abstract model of how
> software MIGHT be built, but not the concrete evaluation of what works
> and what doesn't.

This is because as such software engineering would have to be a species
of social science. Social science has FAILED to model human behavior.

>
> I understand that like experimental/quantitative economics, taking a
> practical approach to software is a lot more work than is proposing
> philosophy or theory.  But practice is a hell of a lot more useful too.

This is self-contradictory for what you want is a theory of practice.
News fa-lash: you can't teach (unless you are a stupid, vulgar, vile
and dishonest clown like Donald Trump) practice in the sense of a set
of maxims for success, for the "set of maxims" is a THEORY.
>
>      Randy
>
> --
> Randy Crawford   http://www.ruf.rice.edu/~rand   rand AT rice DOT edu

In article <1118037562.171515.250880@o13g2000cwo.googlegroups.com>,
 <spinoza1111@yahoo.com> wrote:
>
>
>Gregory L. Hansen wrote:
>> I've been seeing discussions here and elsewhere about computer science
>> programs that don't teach software engineering.  Software engineering
>> clearly has a practical role since people are writing software all over
>> the place.  But how does computer science fit into it?  Is that one of
>> those things whose primary product is scholarly articles, or does it do
>> much to inform the typical maker of software?  Do programmers find
>> themselves well served by their CSCI degree, or do they tend to have to
>> learn a lot of stuff that just wasn't taught in school?
>
>Considered as "success in implementing software", "software
>engineering" has little to say because in fact there is little success
>(with an 80% failure rate according to some sources).

That seems like something that should be aggressively addressed.

>
>If the SE student desires his personal success he may as well learn
>that in a laissez-faire economy nobody has any interest in teaching him
>how to steal their ricebowl and that in this regard much (not all) of
>software engineering is like learning options, puts and calls. The
>personally successful are too busy making money.

Electrical engineers, mechanical engineers, civil engineers, and others, 
learn their craft in school.  They learn how to make bridges that don't 
fail, radios that don't change stations unexpectedly-- they learn how to 
design.  They study methods of quality assurance.  They have 
state-governed certifications, and it's required that a PE sign off on a 
project like a bridge design.  But software engineers should be dumped 
into the piranha tank to figure it out on their own?

From your opinion it would seem that software engineering can hardly be 
called engineering at all!  It's not up to the standards of any other 
engineering field.  At least not in the US.  By contrast, India has been 
working hard to import IT work.  That includes an intensive effort on 
quality, they make it one of their major selling points, and CMM 5 shops 
are the norm in that country.  

>
>Good programmers on the other hand are precisely who use computer
>science. Period. They use it to the point of resistance to that part of
>"software engineering" which is constituted in learning subservience.

My question was triggered in part by the gentleman who had been through a 
computer science program and still wasn't sure what OOP is.  Elsewhere 
someone mentioned a fellow who had completed a computer science degree 
without writing any code at all.  That didn't seem like adequate 
preparation when the end result of a computer science degree so often is 
someone that writes software.  But all the employers still want to see the 
bachelor's degree.


-- 
"The preferred method of entering a building is to use a tank main gun 
round, direct fire artillery round, or TOW, Dragon, or Hellfire missile to
clear the first room." -- THE RANGER HANDBOOK U.S. Army, 1992 

Gregory L. Hansen wrote:
> 
> I've been seeing discussions here and elsewhere about computer science
> programs that don't teach software engineering. 

Computer science,
What is it good for?
Absolutely nothing!
Say it again.
Computer science,
What is it good for?
Absolutely nothing!

Computer science has shattered many young men's dreams,
Made them disabled bitter and mean.
Life is too precious to be computing each day.
Computer science can't give life it can only take it away.

-- 
pete

In article <42A46EDE.A4A@mindspring.com>, pete  <pfiland@mindspring.com> wrote:
>Gregory L. Hansen wrote:
>> 
>> I've been seeing discussions here and elsewhere about computer science
>> programs that don't teach software engineering. 
>
>Computer science,
>What is it good for?
>Absolutely nothing!
>Say it again.
>Computer science,
>What is it good for?
>Absolutely nothing!
>
>Computer science has shattered many young men's dreams,
>Made them disabled bitter and mean.
>Life is too precious to be computing each day.
>Computer science can't give life it can only take it away.

Recent grad?


-- 
"The hardest conviction to get into the mind of the beginner is that the 
education he is receiving in college is not a medical course but a life 
course for which the work of a few years under teachers is but a 
preparation." -- Sir William Osler

spinoza1111@yahoo.com wrote:
> Randy wrote:
>>Gregory L. Hansen wrote:
....
>>Computer science (as it's taught and researched in academia) has
>>almost nothing to do with the development of software solutions.  CS
> 
> This is simply incorrect. Most workable solutions are based on some
> form of cs. 

Yes, and most unworkable solutions are based on some form of CS.  Most
software runs, does something, and terminates.  Thus the principles of
CS are served (the halting problem is avoided).

The problems with most software are that it arrives late; it doesn't
serve the purpose for which it was intended; its source code is
incomprehensible to outsiders; the solution space's abstraction does not
match up well with the problem space's abstraction (or the
implementation); it's fault intolerant, etc, etc.

These should ALL fall under the rubric of CS.  Instead CS chooses to
look away.

> It is characteristic of unworkable solutions that they are not.

Most workable software designs are not based on CS principles at all.
Efficiency is what CS cares about, not usability, reliability,
coherence, or even conformance to the initial requirements.  That's
someone else's problem -- just as long as the program halts.

Efficacy must trump efficiency, always.  CS has yet to learn this.

> 
>>focuses on individual computational techniques, but does not integrate
>>these into a whole nor does it deal in the pragmatics of using
>>software to solve user needs.  CS curricula use software to solve
>>homework problems, not user problems.
> 
> 
> At Princeton this "homework" at senior level consists of developing a
> complete hardware and software system. At DeVry at the other end of the
> scale it consists in setting up a complete network.

Setting up a network is part of CS?  I see no connection between
installing a LAN and practicing computer science.

As to Princeton, did this practicum involve legacy code or did the
students start anew?  Did they first sit down with the customer to learn
what needs they had before they began their design?  Probably no to both.

I think such labs (or capstone projects) are useful and interesting.
But like most CS departments, Princeton sees itself as preparing
students to become professors.  Most software pros will never work below
the level of a library API, much less O/S, and never below assembly.
That Princeton goes that low is testament to a different agenda than the
preparation of software professionals who will serve the needs of 99% of
business.

> 
> Universities have long emphasized integration and much of cs is about
> that form of "integration" that results naturally from factoring and
> analysis.

Are you aware of any college CS courses in refactoring?  I am not.

> 
> The missing element in the university is the cash nexus between the
> developer and employer and this changes everything into a struggle, not
> to develop the best system, but to develop the system with the least
> amount of intellectual effort (thereby favoring the developer) in the
> shortest amount of time (in the company's interest).

And that serve the need of the user.  You forgot that most important
point.  Which helps prove my point, actually...

> 
>>This is partly because almost all professors have never been in the
>>trenches, producing code under a deadline, with a customer 1) who
> 
> 
> Completely false. At the high end Brian Kernighan started out at Bell
> Labs and many CS profs have formed their own business. Likewise at the
> low end.

Are you claiming that Brian Kernighan is representative of CS profs?
The fact that all of Bell Labs' staff left for academia (e.g. Stroustrup
is at Texas A&M) does not make them them representative of most CS
academics.

"Completely false".  Boy is THAT a waste of breath.  It's easy to offer
bare condemnation; it's substantiation that's needed.  Look at *any* CS
department.  Note the number of profs (especially tenured) who have any
industry experience.  The fraction is tiny, perhaps 5%.  That's
substantiation.

And Bell Labs is hardly an example of "industry", much less a positive
example.

> 
> It may be a comforting myth to believe that by definition a college
> professor in an APPLIED discipline doesn't know about rough and tough
> realities but the problem is you go to the professor of an APPLIED
> discipline to learn how to APPLY theory to practice.

It's not comforting.  It's alarming.  It's inappropriate.  As such, CS
is not engineering.  It's counter to preparing most professionals to
serve their future employers.  It's a BAD THING.

> 
> So what you end up claiming is that our society subsidizes a class of
> professors who don't know their ass from a hole in the ground despite
> the fact that as in the case of Kernighan they started out in the
> corporation and toplevel cs profs have long been in demand at levels
> above "programming".

What's with Kernighan as the epitome of CS academics?  He's unlike any
CS prof I know.  Until he and the rest of Bell Labs were evicted, he did
not teach, nor is he renowned for research.  As such, he's a poor
representative example of "the academic".

No slight intended toward Kernighan.  But his fame is not for doing
research as much as for pioneering implementations (and writing a book).
 By that standard, Steve Jobs and Andy Herzfeld should be professors
because of their work on Macintosh or Peter Norton for writing his many
books on the pioneering of personal computing.

> 
> I find this all rather hard to believe. Instead I think what happens is
> that anhedonic and alienated students flock into CS programs and fail
> to master their trade.

I suggest "anhedonic" (good obfuscatory word, that) students and
otherwise are likely to fail to live up their potential because CS is an
orphan discipline.  It's not an engineering, since engineering is all
about choosing among design alternatives and building solutions that
serve their purpose effectively.  CS has no such priority.

Nor is CS a science, since it's entirely abstract and does not extend
into the physical world.  It's a rare CS course that considers feedback
or uses metrics to drive design or decision making.  That's unlike any
form of engineering or science that I know.  (Yes, courses in algorithms
are the exception.)

Academic CS is presented largely an extension of mathematics.  It
shouldn't be.  That's my thesis.

> 
> Nearly all of CS is about making problems including "software
> engineering" intellectually manageable. Your claim is that it has
> failed yet Open Source shows you're wrong because it characteristically
> uses a bit "more" CS (Linux, for example, developed by a CS grad
> student, not a "software engineer").

Open Source is laudable, but it's a self fulfilling prophecy.  An Open
Source project succeeds not because a need was defined and then a
product built.  It succeeds because someone built a product in the
belief that "he would come" (others would also be interested).

With open source, there is no customer; there is no obligatory time
frame to delivery; there is no required level of performance or fault
tolerance or anything measure of success other than mindshare.  Open
Source is fundamentally about role playing.  Dungeons and Dragons in
source code...

There are exceptions to this in Open Source.  But Linux and GCC and
Apache are departures from the rule.  The vast majority of Open Source
began and was perpetuated by hobbiests building something for their own
use, having a good time, and hoping to get their names in lights.  It's
not the software model that almost any business uses.  As such, its a
poor basis on which to measure success or failure among software
engineering enterprises.

> 
> Basically, what the computer scientist must master in 'software
> engineering' is a form of personnel management and a *bricolage* of
> negative capabilities which cause actual developers to cut corners and
> put in extra hours as needed.
> 
> This cannot be "taught".

Processes can be taught.  Econometrics can be taught.  Lessons can be
learned, at least in terms of what does NOT work.  Engineering curricula
are full of this sort of stuff.  CS curricula are not.

> 
> Well, human beings as such already know how to extract surplus value
> from each other. If the university got into the business of teaching
> how to pimp other people who want to pay you as little as possible,
> then for it to succeed, simple microeconomic reasoning would tell us
> that nobody would make any money. All actors would have full
> information and the game would be zero sum.

Formal system theory like this assumes a lot: that everyone behaves
predictably and never loses information and plays by the same rules.
They don't of course.  Nor do customers know what they want, what's
possible, nor what will work best within their business model.  Often
they don't even know what's wrong with their current business model.  If
CS professionals do only what they're told by customers, they'll fail
nine times out of ten.

CS needs to recognize the value of feedback in all its forms.  IMHO,
this may be the Achilles heel of the discipline.  Software is not
getting better.  Who's fault is that?  I think it starts with the
"experts" in the field.  If your field performs poorly, that *ought* to
reflect poorly on its gurus.  Oddly enough, it hasn't.

> 
>>Making architectural tradeoffs under such circumstances is an entirely
>>different enterprise from assessing an algorithm's asymptotic
>>complexity.  The latter is still valuable but the former is essential:
>>it's the life blood of business.  But on the radar screen of CS
>>academics, the needs of business or the user don't rate even a tiny
>>dot.  That's why courses in software engineering, application domains,
>>and "designing for the user" are rare as hen's teeth in CS.
> 
> 
> This can only be taught in the vulgar and stupid fashion of Donald
> Trump in the Apprentice.

Your degree is not in engineering, is it?

The issue is not about aesthetic beauty.  It's about efficacy.  To hell
with Trump or television.  Either you get the job done well or you do it
poorly.  For the past 40 years, software solutions have sucked.  And
they're not getting better.  Why is that?

Yes, practice is the ultimate teacher.  But if CS cannot add more value
than it does today, perhaps we should look elsewhere to educate future
software engineers...

....
> 
> Software engineering has to "teach" in this irresponsible manner, by
> means of the case study.
> 
> The problem with the case study is that it is post facto, and NO
> generalizations can be scientifically made from it, because its base
> entities are chaotic and complex systems (people and companies).

Nah.  All enterprises benefit from analysis.  For example, Kinsey made
huge strides toward better understanding of processes that are a hell of
a lot more chaotic than software (sex).  Business is inherently complex
(though hardly chaotic).  Business practices can definitely be
streamlined and improved.  (For example, Six Sigma has many successes.)

American software is going to have to get with it, or Indian/Chinese/
Korean/Russian/Brazilian software is going to kick its ass.  Already,
there are more CMM level 5 shops in India than in the US.  Most
graduates of US CS programs have never heard of CMM.  That's absurd.

> 
> The State of Virginia wasted five years and millions of dollars trying
> to use a Peoplesoft client-server system for human resources, only to
> scrap it and write the needed functionality in five months using Java.

Is that a condemnation of the entire state of Virginia, or their IT
management, or Peoplesoft?  I'd say it's none of these, but a lack of
standard criteria that can be applied to comparable enterprises in the
past that should have served this project as prologue.  If the VA
management ignored such criteria, then shame on them.  If the criteria
do not exist, then shame on the software business.

> 
> Nothing can be really learned from this narrative, for the failure may
> have taught Peoplesoft to pay more attention to nonprofits in such a
> way that it does a markedly better job in meeting their needs. Nor does
> it mean that Java is intrinsically faster.

Dammit, NO.  What *can* be learned is that a given approach failed.  If
we do not pay attention to what doesn't work, then we'll just keep on
repeating the same failures.  That's EXACTLY what I'm saying is
happening in CS.  The fact that you think there is no recourse but to
keep doing the same thing that failed is testament to the failure make
you believe in and try to improve on current practices.  (That, or the
lessons were there, but you just skipped class that day.)

I don't mean to be combative or pejorative, but your attitude is
alarming.  There's no way a smart guy who apparently attended Princeton
should persist with doing things that he knows do not work.  Worse yet,
to believe that no improvement is possible.  That's just nuts.

> 
> Other than the case study, what does software engineering provide?
> Nothing of substance beyond operations research and computer science.

There's software engineering as a science -- which I would agree is a
failure.  There's also software engineering as a practice -- which I
would disagree in saying can be improved and often is.  CMM levels are
an informal model that emphasizes the value and application of feedback
in improving software lifecycle practices.  Certainly, if I were a
software product manager and my company was competing with another
software product team that was performing at several CMM levels higher
than we were, I'd be concerned about our competitiveness.

....
> 
> The vulgar meaning of "works" in software is "gawrsh, my program
> consumes resources without crashing, and the user is all happy". The
> problem (as seen in the manufacture of reasons for the Iraq war) the
> user may be happy because the answers provided by the software meet his
> agenda.
> 
> Of course, computer science has nothing to contribute to this form of
> grab-ass.

So does engineering, but that's a good thing.  Engineering quantifies
how much grab-ass is going on and of what kind, and what works and what
doesn't.  Unfortunately, CS doesn't do any of this.  Academic CS and
S/WE still believes that if you start with beautiful principles, flowers
will inevitably bloom.

> 
>>- analyzing the need for a given software solution, designing the
>>   software, testing it, or learning from your mistakes and building
>>   better software in the future
> 
> 
> "Learning from your mistakes and building better software in the
> future" isn't taught, or teachable.

Go home, young man.  Change careers.  This attitude is going to serve
you poorly everywhere you go.

All enterprises can be improved upon.  All practitioners can get better
at what they do, no matter what it is.  But if you ignore feedback, then
you're right -- you'll never improve.

> 
> If it is a form of office groveling, universities shouldn't teach
> people to grovel. My own university's motto was Education for Freedom.

No doubt it was in Latin.  It's just as meaningless, however.
Universities have a poor understanding of business, even among business
departments.

Groveling and learning from the consumer of your product or service are
hardly the same thing.  If you refuse to listen because you're afraid of
groveling, I suggest that your next degree be in divinity.  You'll be
unhappy working anywhere else.

> 
> If on the other hand it is the humility of the learned man who (without
> some corporation needing to tell him) is always learning, because like
> Master Kong (Confucius) he asks
> 
>    "Is it not a pleasure, having learned something, to try it out
>     at due intervals? Is it not a joy to have friends come from afar?
>     Is it not gentlemanly not to take offence when others fail to
>     appreciate your abilities?"
> 
> then philosophy, not software engineering, teaches this.

Geez.  A quote from Confucius that justifies snobbery.

Yeah, philosophy teaches a lot of things.  The useful lessons are the
ones that help you to improve your performance on those things that
matter to you.  If you want to stay employed, you'd better think about
learning how to serve the needs of your employer, regardless of whether
s/he reads Confucius.

> 
> As to "analyzing the need". Guess what? At the top level (hey, do we
> need this enterprise requirements planning system, or what?) computer
> science AND software engineering are silent. They can advise the CEO as
> to what it will cost but the decision is that of the CEO and it's a
> policy decision.

NO.  That's where failure begins.  The decisions of how software should
work need to be made from the bottom up not from the top down.  The
folks who use the software have a job to do.  It's the role of the
software to make that job easier and more efficient.  The process of
designing that software solution cannot be driven by edicts that arise
from on high.  Nobody above a line manager should ever be involved in
software development decisions.  The requirements for the software
cannot be defined abstractly; they must be observed from current
business practices, and then ideally, iteratively prototyped by
observing software users who try to use the new software in a new way
that *should* be an improvement on the status quo.

Otherwise, what's a heaven for?

> 
> I realize, however, that a favorite form of American corporate grab-ass
> is to say of an enterprise system that "we didn't want it", but this
> grab-ass is basically that American CEO gesture of denying
> responsibility for what happened on his watch as seen at Enron.
> 
> I am not denying that the CEO has a real problem. This is that the
> "materiality", the hardware and software, of a data system is by
> definition always surplus to his business.

Software has nothing to do with upper management.  CEOs have no business
getting anywhere near software, unless they sell it.

> 
> Indeed it has been shown that "enterprise" systems seldom make
> companies a dime. Instead they cause a qualitative transformation that
> allows the first adopter of an enterprise model to create a market as
> in the case where Barnes and Noble, Amazon and Borders use modern data
> bases to do business in a new way.

I agree that software is about doing business better.  But most software
is even more infrastructural than the examples you offer.  It shapes
business practices.  It *becomes* business practices.  The ideal form
for software is to make the abstract model of a given business
incarnate.  When that is achieved, and as much of the work expedited and
automated, the business reaches satori.

Obviously, few businesses are so enlightened.

> 
> The operations research and "tradeoffs" of software engineering are
> useless in counseling companies how to take a leap into a void.

Sigh...  You are truly in the wrong business.  If you really live by
your words, your customers will learn to hate you with a passion.  Your
bosses won't be too happy with you either.

....
>>
>>I've always been amazed that NOBODY in academia has laid claim to the
>>agenda of experimental software engineering.
....
> 
> This is because as such software engineering would have to be a species
> of social science. Social science has FAILED to model human behavior.

Yeah, we haven't built the perfect beast just yet.  But to claim that
social science has has no successes is just specious.  That's equivalent
to saying that business has found no way to improve its efficiency
through considering work practices.  And that's downright silly.

> 
>>I understand that like experimental/quantitative economics, taking a
>>practical approach to software is a lot more work than is proposing
>>philosophy or theory.  But practice is a hell of a lot more useful too.
> 
> 
> This is self-contradictory for what you want is a theory of practice.
> News fa-lash: you can't teach (unless you are a stupid, vulgar, vile
> and dishonest clown like Donald Trump) practice in the sense of a set
> of maxims for success, for the "set of maxims" is a THEORY.

"Theory of practice" is the oxymoron.  "Whatever works" is the lesson.

    Randy

-- 
Randy Crawford   http://www.ruf.rice.edu/~rand   rand AT rice DOT edu

In article <d825oi$4od$1@joe.rice.edu>, Randy  <joe@burgershack.com> wrote:
>spinoza1111@yahoo.com wrote:
>> Randy wrote:
>>>Gregory L. Hansen wrote:
>...
>>>Computer science (as it's taught and researched in academia) has
>>>almost nothing to do with the development of software solutions.  CS
>> 
>> This is simply incorrect. Most workable solutions are based on some
>> form of cs. 
>
>Yes, and most unworkable solutions are based on some form of CS.  Most
>software runs, does something, and terminates.  Thus the principles of
>CS are served (the halting problem is avoided).
>
>The problems with most software are that it arrives late; it doesn't
>serve the purpose for which it was intended; its source code is
>incomprehensible to outsiders; the solution space's abstraction does not
>match up well with the problem space's abstraction (or the
>implementation); it's fault intolerant, etc, etc.

Oh, boy, a fight!  I need a beverage for this one.

>> Universities have long emphasized integration and much of cs is about
>> that form of "integration" that results naturally from factoring and
>> analysis.
>
>Are you aware of any college CS courses in refactoring?  I am not.

Programs must vary.  A CSci degree at the University of Minnesota 
includes these required courses:

CSCI 1901  - Structure of Computer Programming I
Principles of programming. Different programming paradigms 
(message-passing, data-driven, event-driven). Students develop 
algorithms/data types using language such as Scheme and techniques such as 
abstraction, procedures, recursion, iteration.

CSCI 1902 - Structure of Computer Programming II
Object-oriented programming using language such as C++ or Java. Builds on 
1901, presenting additional data structures/algorithms. Object-oriented 
approach to implement data structures/operations as abstract data types.

CSCI 3081W  - Program Design and Development (WI)
Principles of programming design/analysis. Concepts in software 
development. Uses C/C++ language to illustrate key ideas in program 
design/development, data structures, debugging, files, I/O, state 
machines, testing, and coding standards.

At least the student can't graduate without doing some coding.  There are 
other courses that cover pattern recognition, data mining, natural 
language processing, and robotics, and I've seen all of those skills 
requested in one job listing or another.

The U of MN also has these courses.  They're apparantly not required, but 
their existence is heartening.

CSCI 5801  - Software Engineering I
Advanced introduction to software engineering. Software life cycle, 
development models, software requirements analysis, software design, 
coding, maintenance.

CSCI 5802 - Software Engineering II
Introduction to software testing, software maturity models, cost 
specification models, bug estimation, software reliability models, 
software complexity, quality control, and experience report. Student 
groups specify, design, implement, and test partial software systems. 
Application of general software development methods and principles from 
5801.

>> Well, human beings as such already know how to extract surplus value
>> from each other. If the university got into the business of teaching
>> how to pimp other people who want to pay you as little as possible,
>> then for it to succeed, simple microeconomic reasoning would tell us
>> that nobody would make any money. All actors would have full
>> information and the game would be zero sum.
>
>Formal system theory like this assumes a lot: that everyone behaves
>predictably and never loses information and plays by the same rules.
>They don't of course.  Nor do customers know what they want, what's
>possible, nor what will work best within their business model.  Often
>they don't even know what's wrong with their current business model.  If
>CS professionals do only what they're told by customers, they'll fail
>nine times out of ten.

I'd almost think the computer science student should select a few courses 
from business management.

>> Software engineering has to "teach" in this irresponsible manner, by
>> means of the case study.
>> 
>> The problem with the case study is that it is post facto, and NO
>> generalizations can be scientifically made from it, because its base
>> entities are chaotic and complex systems (people and companies).

Oh, case studies are a wonderful addition to an education.  They give a 
concrete example of abstract principles.  You get something out of a case 
study when you ask "Why?"  Why was Peoplesoft a bad choice, how could the 
State of Virginia have anticipated that, how can that be generalized to an 
arbitrary entity determining the suitability of an arbitrary product for 
an arbitrary task?  

>
>> 
>> Nothing can be really learned from this narrative, for the failure may
>> have taught Peoplesoft to pay more attention to nonprofits in such a
>> way that it does a markedly better job in meeting their needs. Nor does
>> it mean that Java is intrinsically faster.
>
>Dammit, NO.  What *can* be learned is that a given approach failed.  If

Somewhere there was an insufficient requirements analysis, or vendor 
negotiation, or a problem was allowed to continue far longer than it 
should have been, or something of the sort.  There are lessons to be 
learned if it's analyzed and generalized.

-- 
"The polhode rolls without slipping on the herpolhode lying in the 
invariable plane." -- Goldstein, Classical Mechanics 2nd. ed., p207.

Randy wrote:
> spinoza1111@yahoo.com wrote:
>> Randy wrote:
> ...
>>> Computer science (as it's taught and researched in academia) has
>>> almost nothing to do with the development of software solutions. 
>>
>> This is simply incorrect. Most workable solutions are based on
>> some form of cs.
> 
> Yes, and most unworkable solutions are based on some form of CS. 
> Most software runs, does something, and terminates.  Thus the
> principles of CS are served (the halting problem is avoided).
> 
> The problems with most software are that it arrives late; it
> doesn't serve the purpose for which it was intended; its source
> code is incomprehensible to outsiders; the solution space's
> abstraction does not match up well with the problem space's
> abstraction (or the implementation); it's fault intolerant, etc,
> etc.
> 
> These should ALL fall under the rubric of CS.  Instead CS
> chooses to look away.

....<gargantuan snip of 450 or so lines>...

This is a lot of foolishness.  CS science tells us such things as
"a bubble sort won't work well on 10,000 items", but that "A
mergesort will be much faster, and here's what to expect", or "this
problem is not tractable with any known methods, so don't waste
your time trying to apply them".

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

Randy wrote:
> spinoza1111@yahoo.com wrote:
> > Randy wrote:
> >>Gregory L. Hansen wrote:
> ...
> >>Computer science (as it's taught and researched in academia) has
> >>almost nothing to do with the development of software solutions.  CS
> >
> > This is simply incorrect. Most workable solutions are based on some
> > form of cs.
>
> Yes, and most unworkable solutions are based on some form of CS.  Most
> software runs, does something, and terminates.  Thus the principles of
> CS are served (the halting problem is avoided).
>
> The problems with most software are that it arrives late; it doesn't
> serve the purpose for which it was intended; its source code is
> incomprehensible to outsiders; the solution space's abstraction does not
> match up well with the problem space's abstraction (or the
> implementation); it's fault intolerant, etc, etc.

Most authorities, from the Harvard Business Review on down, describe
this as a problem which takes place in management space, not computer
science space, as the result of choices by management.

"It arrives late?" You have to explain what "late" means.

Basically, the building of an enterprise system is always, and without
exception, surplus to the business of an organization.

The organization's CEO is already concerned with a range of issues
which occupy 100%+ of his time but during the development of an
enterprise system (including the installation of a "package" like
Oracle or Peoplesoft which today is equivalent in scope to a new
system, demanding extensive customization in the best case), the CEO
has to also guide, presumably on his lunch hour, the creation of the
enterprise system.

In this context, the system is by definition "late". The structure of
the situation simply doesn't allow it any time of its own.

"It doesn't serve the purpose?" Again, quite vague. I agree that what's
politely described as a communications breakdown between the CIO and
CEO can cause this but my take is that this so-called communications
breakdown is in reality a conflict of self-interest, papered over by
the pretense of a common interest of corporate *bien-pensance*.

"The code is incomprehensible to outsiders?" My experience is that this
seldom occurs in any absolute sense anymore, and also that once you
grok the code as a formal language in its own right, it's
"comprehensible".

There are any number of people for whom the "clearest" code is
Sanskrit. But there are also thousands of educated Indiamen for whom
Sanskrit is quite clear...along with C++, in fact.

I am really tired of the unfactored use of "clarity", and the
uninstantiated use of "unclarity" by people who hurl these charges
owing to an unwillingness to work. There is an absolute unclarity, but
it is almost always at the semantic level and associated with simple
incorrectness.

Industrial development takes place in a context which can allow it no
independent existence. As such, it is no surprised that it's always a
rush job.

>
> These should ALL fall under the rubric of CS.  Instead CS chooses to
> look away.
>
> > It is characteristic of unworkable solutions that they are not.
>
> Most workable software designs are not based on CS principles at all.
> Efficiency is what CS cares about, not usability, reliability,
> coherence, or even conformance to the initial requirements.  That's
> someone else's problem -- just as long as the program halts.
>
> Efficacy must trump efficiency, always.  CS has yet to learn this.

This is complete nonsense and betrays an ignorance of CS, because one
of its contributions happens to be the theory of computational
complexity (or abstract time and space efficiency). From this theory
flows advice as to when it makes sense to use the slower algorithm and
when not.

>From CS you learn (in CS 101 for boneheads) when not to waste time
implementing a binary search because your list contains fewer than 100
entries.

>
> >
> >>focuses on individual computational techniques, but does not integrate
> >>these into a whole nor does it deal in the pragmatics of using
> >>software to solve user needs.  CS curricula use software to solve
> >>homework problems, not user problems.
> >
> >
> > At Princeton this "homework" at senior level consists of developing a
> > complete hardware and software system. At DeVry at the other end of the
> > scale it consists in setting up a complete network.
>
> Setting up a network is part of CS?  I see no connection between
> installing a LAN and practicing computer science.
>
> As to Princeton, did this practicum involve legacy code or did the
> students start anew?  Did they first sit down with the customer to learn
> what needs they had before they began their design?  Probably no to both.

What cannot be reproduced, by definition, in a university, is the
phenomenology of "sitting down" with a "customer" who has all sorts of
problems on his plate to whom IT represents surplus annoyance, period,
while you have bills to pay. The FEELINGS on either side, which are
strictly an artifact of social relations including economic inequality,
cannot be induced, any more than a flight simulator can simulate the
pilot's experience of "hours of boredom and seconds of terror".

You're asking for basic training with live ammo. But for the same
reason military recruits have I think a human right to basic training
in a reasonably safe environment (something provided even by elite,
spetznaz, *stosstruppen*, Seals and Airborne units), IT personnel
deserve a chance to learn theory.

Indeed, your arguments create an infinite regress. Just as you'd need
basic training for basic training if basic training used live
ammunition, if cs education actually simulated the systematic brutality
of the business world (including the provision of too little time for a
systems development effort so as to in effect force the developers to
work extra hours) then you'd need to spend what spare time is left
learning theory in a non-brutalized environment.

Ultimately, the demand for utmost "practicality" of education is
barbaric because it demands that education be replaced by the
conditions of a world for which education is supposed to be a
preparation: see Rousseau's Emile.

It's both barbaric, and as is the case with most contemporary forms of
barbarism, have-your-cake-and-eat-it-to, as well as
take-their-cake-and-eat-that-too, followed by let-them-eat an
expropriated *gateau*.

DeVry University campuses replicate the physical environment of the
corporation. As an adjunct there, I showed up on time (actually an hour
earlier), took attendance, and used the snappy voice of the drill
instructor rather than the mumbles of the prof. This was all to the
good since the students had paid for real preparation for white-collar
jobs.

But I could not, by definition, place myself in the role of the
student's "real" boss and had to do things with a grain of salt and a
wink. They had to meet my expectations in a fundamentally educational
relation in which I was their prof and not their boss.

For example, I was expected to be fair. I could only mention, *en
passant*, that the business world isn't "fair".


>
> I think such labs (or capstone projects) are useful and interesting.
> But like most CS departments, Princeton sees itself as preparing
> students to become professors.  Most software pros will never work below
> the level of a library API, much less O/S, and never below assembly.
> That Princeton goes that low is testament to a different agenda than the
> preparation of software professionals who will serve the needs of 99% of
> business.

This is the post-facto Trump logic.

Embedded programmers who because they haven't learned their trade
except in an artisanal fashion on the job will say, from their
position, than "CS overemphasises high level approaches useless for our
jobs such as C++": MIS programmers will say, based on their experience,
that "CS teaches low level programming to excess".

Are you even aware that Kernighan of Princeton SOLVED the puzzle of low
level versus high level in C which can be used in BOTH ways?

The guy at Princeton, who was a straight A student and a track star,
built a system from the ground up and I believe he used C, not
"assembler" for the software. FYI he was then personally recruited by
Bill Gates and is now not a college professor but a Microsoft
executive.

What I find hard to understand is the claim "I do not need to know
that", because I would think that education for human freedom would
include the instillation of curiosity.

I say this because in my experience, real MIS problems are solved by
transgressing these Urban Legends, these myths by people like me who
haven't gotten the word that we're supposed to be practical.

In my <shamelessPlug> book, Build Your Own .Net Language and Compiler
(APress 2004) </shamelessPlug>, I describe an "MIS" system on the verge
of failure, a switch billing system that was failing to uh send bills
out because it was written in a "structured" Cobol that was a
"structured" mess of small Procedures that the original developer had
failed to master, and as a result the program couldn't bill properly
for call forwarding, conference calling, and so on.

But in 1972, I had read and worked the problems in a "computer science"
text, Formal Languages and their Relation to Automata, by Jeffrey
Ullman and Jeff Hopcroft, both, as it happened, from Bell Labs and
Princeton.

In this book they showed me how to create a simple and limited form of
program constituted in a state transition table and how this program
related to a class of languages, and at the client I realized that the
"switch billing" program could recreate complex calls from events IF
ONLY it simulated the state transitions of the underlying switch.

I threw out the old code, and developed a switch billing system based
on state transitions in two weeks, and the customer was all "happy".

Another example is the trucking company which hired an unlettered
"computer consultant" to create another mess for planning liquor
delivery routes...that now uses the simulated annealing solution to the
traveling salesman problem as the near-optimal solution. The discovery
of simulated annealing and the discovery of a class of good-enough
solutions happened on computer science's watch in the university.

Because so often I see flaws in enterprise systems based on ignorance
of CS I comclude that the language of "practicality" is a tool of
social control.

>
> >
> > Universities have long emphasized integration and much of cs is about
> > that form of "integration" that results naturally from factoring and
> > analysis.
>
> Are you aware of any college CS courses in refactoring?  I am not.

No, but I am aware of Bjarne Stroustrup's work in OO design which
includes and transcends "refactoring".

>
> >
> > The missing element in the university is the cash nexus between the
> > developer and employer and this changes everything into a struggle, not
> > to develop the best system, but to develop the system with the least
> > amount of intellectual effort (thereby favoring the developer) in the
> > shortest amount of time (in the company's interest).
>
> And that serve the need of the user.  You forgot that most important
> point.  Which helps prove my point, actually...

"Serve the need of the user" is as vague as, and as open to abuse as,
the maxim in Mao's China, as "serve the need of the people".

Idealistic Communists of the Long March generation could "serve the
need of the people" because in the 1930s most every person in China was
a land-hungry peasant set upon by brutal landlords and the crony
capitalists of the cities.

But as soon as China developed to the point of having different sorts
of people they began to fight for the role of "the people" which meant
that by the time of the Cultural Revolution, any conduct could be
justified because "I serve the people and you don't".

What "user" are you talking about? The SAP enterprise system works very
well for many large companies. At the same time, my experience in
enterprise system marketing taught me that in SAP "shops", many real
users don't like the way that SAP imposing the SAP Way or Tao of
thinking on them, but groan under its lash all the same because the
boss said they must serve SAP or else.

I'm sorry to have to tell you this, but education of human beings has
to factor-out their later and empirical positions-with-organizations.

>
> >
> >>This is partly because almost all professors have never been in the
> >>trenches, producing code under a deadline, with a customer 1) who
> >
> >
> > Completely false. At the high end Brian Kernighan started out at Bell
> > Labs and many CS profs have formed their own business. Likewise at the
> > low end.
>
> Are you claiming that Brian Kernighan is representative of CS profs?
> The fact that all of Bell Labs' staff left for academia (e.g. Stroustrup
> is at Texas A&M) does not make them them representative of most CS
> academics.
>
> "Completely false".  Boy is THAT a waste of breath.  It's easy to offer
> bare condemnation; it's substantiation that's needed.  Look at *any* CS
> department.  Note the number of profs (especially tenured) who have any
> industry experience.  The fraction is tiny, perhaps 5%.  That's
> substantiation.

Cite? My experience in graduate school was that the profs at DePaul
were always doing jobs in industry to expand their experience and
supplement their lower salaries.

In fact, my personal experience was that the situation at DePaul was
OVERLY biased in favor of industry's needs-at-the-time. For example, we
had to do labs in PL/I on the IBM mainframe rather than C on a DEC 10.
This was excellent preparation for a job in the loop with some bank
that conventiently would go tits up in the 1980s, not at all for a job
in Silicon Valley.

>
> And Bell Labs is hardly an example of "industry", much less a positive
> example.

Again, education cannot prepare students for barbarism, including the
barbaric destruction of Bell Labs by Lucent, or Bell-Northern Research
by Nortel.

>
> >
> > It may be a comforting myth to believe that by definition a college
> > professor in an APPLIED discipline doesn't know about rough and tough
> > realities but the problem is you go to the professor of an APPLIED
> > discipline to learn how to APPLY theory to practice.
>
> It's not comforting.  It's alarming.  It's inappropriate.  As such, CS
> is not engineering.  It's counter to preparing most professionals to
> serve their future employers.  It's a BAD THING.

You CANNOT educate for slavery. You CANNOT educate people to take jobs
(as at Nortel in 2002) in which they are laid off on the same day they
are hired.

Read Edsger Dijkstra's 1999 address at the University of Texas
(http://www.cs.utexas.edu/users/vl/notes/dijkstra.html):

"By the way, if you got the impression that I have my doubts about
business management as scientific discipline, you are right: it seems
too fickle to be taken seriously. In the 70s, the creed was
diversification, in the 80s, the gospel said to concentrate on your
core business, and in the 90s the world-wide credo seems to be the
intellectual cleansing of the high-tech industries."

"Too fickle to be taken seriously". Here, as usual, Dijkstra gets to
the heart of the matter. For just as the unspeakably vile Trump (a man
with a rich and genuinely successful father, Fred Trump, who is
according to real estate pros a failure at real estate) says one thing
one week and another the next, Dijkstra shows that business can
ultimately only say "succeed financially at what it is you do, and if
you do not, fuck you".

>
> >
> > So what you end up claiming is that our society subsidizes a class of
> > professors who don't know their ass from a hole in the ground despite
> > the fact that as in the case of Kernighan they started out in the
> > corporation and toplevel cs profs have long been in demand at levels
> > above "programming".
>
> What's with Kernighan as the epitome of CS academics?  He's unlike any
> CS prof I know.  Until he and the rest of Bell Labs were evicted, he did
> not teach, nor is he renowned for research.  As such, he's a poor
> representative example of "the academic".
>
> No slight intended toward Kernighan.  But his fame is not for doing
> research as much as for pioneering implementations (and writing a book).
>  By that standard, Steve Jobs and Andy Herzfeld should be professors
> because of their work on Macintosh or Peter Norton for writing his many
> books on the pioneering of personal computing.
>
> >
> > I find this all rather hard to believe. Instead I think what happens is
> > that anhedonic and alienated students flock into CS programs and fail
> > to master their trade.
>
> I suggest "anhedonic" (good obfuscatory word, that) students and

I am not trying to obfuscate. But I do note in the real world that some
syndromes are both global and that their label names something so
convenient to the system that it is unfamiliar.

The inability to take any pleasure in symbolic manipulation may account
for enterprise system failure.

> otherwise are likely to fail to live up their potential because CS is an
> orphan discipline.  It's not an engineering, since engineering is all
> about choosing among design alternatives and building solutions that
> serve their purpose effectively.  CS has no such priority.
>
> Nor is CS a science, since it's entirely abstract and does not extend
> into the physical world.  It's a rare CS course that considers feedback
> or uses metrics to drive design or decision making.  That's unlike any

You seem completely unaware with John Hennessy's work on computer
architecture. Most of RISC is far less about reducing the instruction
set (a sideshow) and far more about the econometric justification of
design choices.

> form of engineering or science that I know.  (Yes, courses in algorithms
> are the exception.)

As well as modern computer architecture. Are you even aware of the
quiet revolution that took place in computer architecture after I
studied it in grad school during the hey-day of the VAX and the CISC,
and the dawn of RISC?

It was found in a tight feedback loop between business (Hennessy's own
company MIPS) and academia (Hennessy's position on the Stanford
faculty) that compiler writers could not figure out how to use the VAX
instruction set and this caused a complete rethink AWAY from CISC!

>
> Academic CS is presented largely an extension of mathematics.  It
> shouldn't be.  That's my thesis.


Oh? And what should replace it? Literary theory? Hey, I'm game, but
only as an additive feature.

You sound like Rush Limbaugh. Recently he attacked my kid's high school
in Evanston Illinois for "not teaching about WWII" because ETHS also
teaches global history and multiculturalism. You claim that your
favored topics are being neglected because other topics are covered.

>
> >
> > Nearly all of CS is about making problems including "software
> > engineering" intellectually manageable. Your claim is that it has
> > failed yet Open Source shows you're wrong because it characteristically
> > uses a bit "more" CS (Linux, for example, developed by a CS grad
> > student, not a "software engineer").
>
> Open Source is laudable, but it's a self fulfilling prophecy.  An Open
> Source project succeeds not because a need was defined and then a
> product built.  It succeeds because someone built a product in the
> belief that "he would come" (others would also be interested).
>
> With open source, there is no customer; there is no obligatory time
> frame to delivery; there is no required level of performance or fault
> tolerance or anything measure of success other than mindshare.  Open
> Source is fundamentally about role playing.  Dungeons and Dragons in
> source code...
>
Yeah, but then real companies prefer to use the Open Source product, as
in my experience in China, where companies lack the American dollars to
fund multiple installations of Windows and Visual Studio, preferring
Linux and Eclipse. That's the flaw in your argument.

> There are exceptions to this in Open Source.  But Linux and GCC and
> Apache are departures from the rule.  The vast majority of Open Source
> began and was perpetuated by hobbiests building something for their own
> use, having a good time, and hoping to get their names in lights.  It's
> not the software model that almost any business uses.  As such, its a
> poor basis on which to measure success or failure among software
> engineering enterprises.
>
This is the SAME situation as obtains in corporate programming, where
most production is stillborn. Software is hard. What Herbert Marcuse
called surplus repression makes it twice as hard.

> >
> > Basically, what the computer scientist must master in 'software
> > engineering' is a form of personnel management and a *bricolage* of
> > negative capabilities which cause actual developers to cut corners and
> > put in extra hours as needed.
> >
> > This cannot be "taught".
>
> Processes can be taught.  Econometrics can be taught.  Lessons can be
> learned, at least in terms of what does NOT work.  Engineering curricula
> are full of this sort of stuff.  CS curricula are not.

Crack a book by Morgan Kaufmann. You'll see how wrong you are.

>
> >
> > Well, human beings as such already know how to extract surplus value
> > from each other. If the university got into the business of teaching
> > how to pimp other people who want to pay you as little as possible,
> > then for it to succeed, simple microeconomic reasoning would tell us
> > that nobody would make any money. All actors would have full
> > information and the game would be zero sum.
>
> Formal system theory like this assumes a lot: that everyone behaves
> predictably and never loses information and plays by the same rules.
> They don't of course.  Nor do customers know what they want, what's
> possible, nor what will work best within their business model.  Often
> they don't even know what's wrong with their current business model.  If
> CS professionals do only what they're told by customers, they'll fail
> nine times out of ten.
>
> CS needs to recognize the value of feedback in all its forms.  IMHO,
> this may be the Achilles heel of the discipline.  Software is not
> getting better.  Who's fault is that?  I think it starts with the
> "experts" in the field.  If your field performs poorly, that *ought* to
> reflect poorly on its gurus.  Oddly enough, it hasn't.
>
Not necessarily. In a negative or zero sum discipline, sheer luck is
the determining factor, and Lady Luck doesn't teach classes.

Basically, owing to the convergence of government with corporations,
we're moving towards a default world of criminal gangs and their hired
computer hackers. The problem with education in such a world is that it
mostly consists in cuffing junior Fagins about the head until they
learn the war of all against all.

Take a look at Iraq. Notice how the invasion went through DESPITE wise
counsel and even when the parliament of the Turks (the otiose Turk
having a parliament, of which many Americans were unaware: they didn't
need to learn your "software engineering", they needed to learn
geography and poli sci) banned our troops from the northern marches.

The invasion was planned by a criminal gang with corporate interests in
2002 according to a memo read this week into the Congressional Record
by Sen. Kerry as a basis for the impeachment of the President.

100,000 people died as a result.

This was however, a "successful" "enterprise" system, but not based on
any theory that could be shared in polite company. Teaching the theory
of this praxis would corrupt the young, for the "theory" is might makes
right.

That's based on an analysis of international relations in which one
player has full rights to sovereignity and recognition based on
empirical happenstance (its military might at time t).

The trouble with such an analysis is that it returns international
relations to their preconditions of struggle to get to the position
taken as a given.

In fact, argmentation for the thesis resembles bad reasoning about
software.


> >
> >>Making architectural tradeoffs under such circumstances is an entirely
> >>different enterprise from assessing an algorithm's asymptotic
> >>complexity.  The latter is still valuable but the former is essential:
> >>it's the life blood of business.  But on the radar screen of CS
> >>academics, the needs of business or the user don't rate even a tiny
> >>dot.  That's why courses in software engineering, application domains,
> >>and "designing for the user" are rare as hen's teeth in CS.
> >
> >
> > This can only be taught in the vulgar and stupid fashion of Donald
> > Trump in the Apprentice.
>
> Your degree is not in engineering, is it?
>
> The issue is not about aesthetic beauty.  It's about efficacy.  To hell
> with Trump or television.  Either you get the job done well or you do it
> poorly.  For the past 40 years, software solutions have sucked.  And
> they're not getting better.  Why is that?
>
> Yes, practice is the ultimate teacher.  But if CS cannot add more value
> than it does today, perhaps we should look elsewhere to educate future
> software engineers...
>
Whatever. How about the Marines? Oops, military software fuckups just
as common. Why is that?

> ...
> >
> > Software engineering has to "teach" in this irresponsible manner, by
> > means of the case study.
> >
> > The problem with the case study is that it is post facto, and NO
> > generalizations can be scientifically made from it, because its base
> > entities are chaotic and complex systems (people and companies).
>
> Nah.  All enterprises benefit from analysis.  For example, Kinsey made
> huge strides toward better understanding of processes that are a hell of
> a lot more chaotic than software (sex).  Business is inherently complex
> (though hardly chaotic).  Business practices can definitely be
> streamlined and improved.  (For example, Six Sigma has many successes.)
>
> American software is going to have to get with it, or Indian/Chinese/
> Korean/Russian/Brazilian software is going to kick its ass.  Already,
> there are more CMM level 5 shops in India than in the US.  Most
> graduates of US CS programs have never heard of CMM.  That's absurd.

Hmm, you have it seems no experience in the gamesmanship I've seen both
in the US and abroad by means of which these certifications are
obtained.

>
> >
> > The State of Virginia wasted five years and millions of dollars trying
> > to use a Peoplesoft client-server system for human resources, only to
> > scrap it and write the needed functionality in five months using Java.
>
> Is that a condemnation of the entire state of Virginia, or their IT
> management, or Peoplesoft?  I'd say it's none of these, but a lack of
> standard criteria that can be applied to comparable enterprises in the
> past that should have served this project as prologue.  If the VA
> management ignored such criteria, then shame on them.  If the criteria
> do not exist, then shame on the software business.
>
> >
> > Nothing can be really learned from this narrative, for the failure may
> > have taught Peoplesoft to pay more attention to nonprofits in such a
> > way that it does a markedly better job in meeting their needs. Nor does
> > it mean that Java is intrinsically faster.
>
> Dammit, NO.  What *can* be learned is that a given approach failed.  If
> we do not pay attention to what doesn't work, then we'll just keep on
> repeating the same failures.  That's EXACTLY what I'm saying is
> happening in CS.  The fact that you think there is no recourse but to
> keep doing the same thing that failed is testament to the failure make
> you believe in and try to improve on current practices.  (That, or the
> lessons were there, but you just skipped class that day.)

Note how in the absence of a genuine theoretical framework, the
infantilization and the infantile charges, based on infantile anxiety,
commence.

When you replace reliable results by the latest management fad, you
bring back the war of all against all, and the result, first, is the
infantilization seen in The Apprentice, in which everyone loudly claims
they "know" but precisely because they are set the one against the
other, nobody "knows" anything.

I've shown you in this post that CS has changed radically as regards
computer architecture. Likewise, cf. Michael Scott's book Programming
Language Pragmatics for the evolution of our understanding of
compilers.

>
> I don't mean to be combative or pejorative, but your attitude is
> alarming.  There's no way a smart guy who apparently attended Princeton
> should persist with doing things that he knows do not work.  Worse yet,
> to believe that no improvement is possible.  That's just nuts.

I not only attended Princeton (couple of at-large classes: my real
academic work happened elsewhere: I was an employee in the computer
dept for five years), I've also worked thirty years in the real world.

At one company I worked at in Chicago, SEI Information Technology (no
relation to SEI in Pittsburgh) senior consultants like me gave weekly
talks on new developments. I spoke on the then-new Pascal and a Polish
cs PhD gave classes in unix and C.

But it was of course impractical for us to convert Chicago clients (who
were struggling with the transition from assembler to Cobol and PL/I)
to unix and C.

However, the companies that stayed overlong with the old paradigm were
swallowed up. Your "practicality" is impractical in the long term.

>
> >
> > Other than the case study, what does software engineering provide?
> > Nothing of substance beyond operations research and computer science.
>
> There's software engineering as a science -- which I would agree is a
> failure.  There's also software engineering as a practice -- which I
> would disagree in saying can be improved and often is.  CMM levels are
> an informal model that emphasizes the value and application of feedback
> in improving software lifecycle practices.  Certainly, if I were a
> software product manager and my company was competing with another
> software product team that was performing at several CMM levels higher
> than we were, I'd be concerned about our competitiveness.
>
> ...
> >
> > The vulgar meaning of "works" in software is "gawrsh, my program
> > consumes resources without crashing, and the user is all happy". The
> > problem (as seen in the manufacture of reasons for the Iraq war) the
> > user may be happy because the answers provided by the software meet his
> > agenda.
> >
> > Of course, computer science has nothing to contribute to this form of
> > grab-ass.
>
> So does engineering, but that's a good thing.  Engineering quantifies
> how much grab-ass is going on and of what kind, and what works and what
> doesn't.  Unfortunately, CS doesn't do any of this.  Academic CS and
> S/WE still believes that if you start with beautiful principles, flowers
> will inevitably bloom.

No, REAL engineering doesn't have to worry about grab-ass, instead
about the limitations of the natural world. Whereas human behavior is
central to software engineering, and it's ultimately immoral to pretend
you can or should control it to the level needed.

>
> >
> >>- analyzing the need for a given software solution, designing the
> >>   software, testing it, or learning from your mistakes and building
> >>   better software in the future
> >
> >
> > "Learning from your mistakes and building better software in the
> > future" isn't taught, or teachable.
>
> Go home, young man.  Change careers.  This attitude is going to serve
> you poorly everywhere you go.
>
> All enterprises can be improved upon.  All practitioners can get better
> at what they do, no matter what it is.  But if you ignore feedback, then
> you're right -- you'll never improve.
>
> >
> > If it is a form of office groveling, universities shouldn't teach
> > people to grovel. My own university's motto was Education for Freedom.
>
> No doubt it was in Latin.  It's just as meaningless, however.
> Universities have a poor understanding of business, even among business
> departments.
>
> Groveling and learning from the consumer of your product or service are
> hardly the same thing.  If you refuse to listen because you're afraid of
> groveling, I suggest that your next degree be in divinity.  You'll be
> unhappy working anywhere else.
>
> >
> > If on the other hand it is the humility of the learned man who (without
> > some corporation needing to tell him) is always learning, because like
> > Master Kong (Confucius) he asks
> >
> >    "Is it not a pleasure, having learned something, to try it out
> >     at due intervals? Is it not a joy to have friends come from afar?
> >     Is it not gentlemanly not to take offence when others fail to
> >     appreciate your abilities?"
> >
> > then philosophy, not software engineering, teaches this.
>
> Geez.  A quote from Confucius that justifies snobbery.
>
> Yeah, philosophy teaches a lot of things.  The useful lessons are the
> ones that help you to improve your performance on those things that
> matter to you.  If you want to stay employed, you'd better think about
> learning how to serve the needs of your employer, regardless of whether
> s/he reads Confucius.

OK, we return here to the lower-middle class anxious kitchen which
controls everything, where Harry and Louise decide national issues
based on false promises and true miseries.
>
> >
> > As to "analyzing the need". Guess what? At the top level (hey, do we
> > need this enterprise requirements planning system, or what?) computer
> > science AND software engineering are silent. They can advise the CEO as
> > to what it will cost but the decision is that of the CEO and it's a
> > policy decision.
>
> NO.  That's where failure begins.  The decisions of how software should
> work need to be made from the bottom up not from the top down.  The
> folks who use the software have a job to do.  It's the role of the
> software to make that job easier and more efficient.  The process of
> designing that software solution cannot be driven by edicts that arise
> from on high.  Nobody above a line manager should ever be involved in
> software development decisions.  The requirements for the software
> cannot be defined abstractly; they must be observed from current
> business practices, and then ideally, iteratively prototyped by
> observing software users who try to use the new software in a new way
> that *should* be an improvement on the status quo.

The problem here is that AT BEST the line manager will decide strictly
from the standpoint of his own job, and AT WORST from his economic
self-interest.

>
> Otherwise, what's a heaven for?
>
> >
> > I realize, however, that a favorite form of American corporate grab-ass
> > is to say of an enterprise system that "we didn't want it", but this
> > grab-ass is basically that American CEO gesture of denying
> > responsibility for what happened on his watch as seen at Enron.
> >
> > I am not denying that the CEO has a real problem. This is that the
> > "materiality", the hardware and software, of a data system is by
> > definition always surplus to his business.
>
> Software has nothing to do with upper management.  CEOs have no business
> getting anywhere near software, unless they sell it.
>
> >
> > Indeed it has been shown that "enterprise" systems seldom make
> > companies a dime. Instead they cause a qualitative transformation that
> > allows the first adopter of an enterprise model to create a market as
> > in the case where Barnes and Noble, Amazon and Borders use modern data
> > bases to do business in a new way.
>
> I agree that software is about doing business better.  But most software
> is even more infrastructural than the examples you offer.  It shapes
> business practices.  It *becomes* business practices.  The ideal form
> for software is to make the abstract model of a given business
> incarnate.  When that is achieved, and as much of the work expedited and
> automated, the business reaches satori.
>
> Obviously, few businesses are so enlightened.
>
> >
> > The operations research and "tradeoffs" of software engineering are
> > useless in counseling companies how to take a leap into a void.
>
> Sigh...  You are truly in the wrong business.  If you really live by
> your words, your customers will learn to hate you with a passion.  Your
> bosses won't be too happy with you either.
>
> ...
> >>
> >>I've always been amazed that NOBODY in academia has laid claim to the
> >>agenda of experimental software engineering.
> ...
> >
> > This is because as such software engineering would have to be a species
> > of social science. Social science has FAILED to model human behavior.
>
> Yeah, we haven't built the perfect beast just yet.  But to claim that
> social science has has no successes is just specious.  That's equivalent
> to saying that business has found no way to improve its efficiency
> through considering work practices.  And that's downright silly.
>
> >
> >>I understand that like experimental/quantitative economics, taking a
> >>practical approach to software is a lot more work than is proposing
> >>philosophy or theory.  But practice is a hell of a lot more useful too.
> >
> >
> > This is self-contradictory for what you want is a theory of practice.
> > News fa-lash: you can't teach (unless you are a stupid, vulgar, vile
> > and dishonest clown like Donald Trump) practice in the sense of a set
> > of maxims for success, for the "set of maxims" is a THEORY.
>
> "Theory of practice" is the oxymoron.  "Whatever works" is the lesson.
>
>     Randy
>
> --
> Randy Crawford   http://www.ruf.rice.edu/~rand   rand AT rice DOT edu

Randy wrote:
> "Theory of practice" is the oxymoron.  "Whatever works" is the lesson.

Selling is what selling sells - The CLASH

"Theory of practice" is not an oxymoron. It's the whole ballgame.

What part of having a theory and putting it into practice independent
of fear or favor do you not understand?

Your misguided philosophy is making corporate programming a hell on
earth because in the absence of an organizing theory bullies take over.

"Whatever works" transforms education into a dreary set of exhortations
to succeed by any means possible, into which rushes religious
fundamentalism, because the content-free exhortations of software
engineering do not satisfy the soul.
>
>     Randy
>
> --
> Randy Crawford   http://www.ruf.rice.edu/~rand   rand AT rice DOT edu

spinoza1111@yahoo.com wrote:
> 
.... snip all 827 lines unread ...

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

CBFalconer wrote:
> spinoza1111@yahoo.com wrote:
> >
> ... snip all 827 lines unread ...

That you're proud of this explains both the software crisis and the
illusions of "software engineering": that we can avoid thinking.
>
> --
> "If you want to post a followup via groups.google.com, don't use
>  the broken "Reply" link at the bottom of the article.  Click on
>  "show options" at the top of the article, then click on the
>  "Reply" at the bottom of the article headers." - Keith Thompson

I'm suprised of how how popular the Computer Science degree is among college
students.It's the first degree to come to mind when someone is thinking of
studying computers in college. Everyone has heard of it too. While writing
drivers, compilers, or embedded systems is exciting stuff, does it reflect
the average programming job in middle America? We don't all live in
beautiful California! During the dot.com boom, from what I understand the
Computer Science degree was sought after among students. Yet wasn't the
dot.com boom mostly a  lot of web development using high level languages? To
me that's something an MIS degree would be more applicable to. Now I know
that writing the actual software itself is something suited for a CS/CE
major, and that's what this thread is about. But even then, how much of that
is there, compared to applications development?

Matt

"Randy" <joe@burgershack.com> wrote in message
news:MtRoe.27069$j51.11277@tornado.texas.rr.com...
> Gregory L. Hansen wrote:
> > I've been seeing discussions here and elsewhere about computer science
> > programs that don't teach software engineering.  Software engineering
> > clearly has a practical role since people are writing software all over
> > the place.  But how does computer science fit into it?  Is that one of
> > those things whose primary product is scholarly articles, or does it do
> > much to inform the typical maker of software?  Do programmers find
> > themselves well served by their CSCI degree, or do they tend to have to
> > learn a lot of stuff that just wasn't taught in school?
>
> Computer science (as it's taught and researched in academia) has
> almost nothing to do with the development of software solutions.  CS
> focuses on individual computational techniques, but does not integrate
> these into a whole nor does it deal in the pragmatics of using
> software to solve user needs.  CS curricula use software to solve
> homework problems, not user problems.
>
> This is partly because almost all professors have never been in the
> trenches, producing code under a deadline, with a customer 1) who
> doesn't know what's possible or what is needed, 2) who needs the
> software now, 3) who wants to pay as little as possible for it.
> Making architectural tradeoffs under such circumstances is an entirely
> different enterprise from assessing an algorithm's asymptotic
> complexity.  The latter is still valuable but the former is essential:
> it's the life blood of business.  But on the radar screen of CS
> academics, the needs of business or the user don't rate even a tiny
> dot.  That's why courses in software engineering, application domains,
> and "designing for the user" are rare as hen's teeth in CS.
>
> IMHO, CS is good preparation for:
> - teaching CS
> - advancing our understanding of the principles of computing
> - speeding up software, networks, or microarchitecture
> - building new software tools (compilers, O/Ses, databases, etc)
> - implementing difficult software components (drivers, kernels, HPC,
>    database engines, compilers, network stacks, etc)
>
> IMHO, CS is poor preparation for:
> - developing software in teams, on time, that works
> - analyzing the need for a given software solution, designing the
>    software, testing it, or learning from your mistakes and building
>    better software in the future
> - managing the lifecycle of a program (including documentation)
> - understanding how software is used (by business or the individual)
> - engineering a software solution as a collection of cost tradeoffs
> - debugging existing code and reducing bugs in future code
> - understanding the user's problem space or mapping software to the
>    problem space
>
> I've always been amazed that NOBODY in academia has laid claim to the
> agenda of experimental software engineering.  There is a CRYING need
> to assess the relative success of different programming models, much
> less quantitatively assessing analysis models, design processes,
> implementation tradeoffs, testing practices, etc.  Oddly, NOBODY in
> academia does this sort of thing.  Even when a department comes along
> that calls itself "software engineering" purportedly to undertake
> these much needed investigations, instead they seem fascinated with
> the theory of software development, as an abstract model of how
> software MIGHT be built, but not the concrete evaluation of what works
> and what doesn't.
>
> I understand that like experimental/quantitative economics, taking a
> practical approach to software is a lot more work than is proposing
> philosophy or theory.  But practice is a hell of a lot more useful too.
>
>      Randy
>
> -- 
> Randy Crawford   http://www.ruf.rice.edu/~rand   rand AT rice DOT edu

"Gregory L. Hansen" <glhansen@steel.ucs.indiana.edu> wrote in message 
news:d82b9h$5b3$1@rainier.uits.indiana.edu...
> In article <d825oi$4od$1@joe.rice.edu>, Randy  <joe@burgershack.com> 
> wrote:
>
> At least the student can't graduate without doing some coding.  There are
> other courses that cover pattern recognition, data mining, natural
> language processing, and robotics, and I've seen all of those skills
> requested in one job listing or another.

I recently had to work with a CS grad who didn't know how to trace a bug in 
OSCommerce - that HE was tasked with setting up. He kept asking me for help. 
No practical coding knowledge at all.

I found it rather sad.

>
> I'd almost think the computer science student should select a few courses
> from business management.

You would think, huh?

Matt wrote:
> I'm suprised of how how popular the Computer Science degree is among college
> students.It's the first degree to come to mind when someone is thinking of
> studying computers in college. Everyone has heard of it too. While writing
> drivers, compilers, or embedded systems is exciting stuff, does it reflect
> the average programming job in middle America? We don't all live in
> beautiful California! During the dot.com boom, from what I understand the
> Computer Science degree was sought after among students. Yet wasn't the
> dot.com boom mostly a  lot of web development using high level languages? To
> me that's something an MIS degree would be more applicable to. Now I know
> that writing the actual software itself is something suited for a CS/CE
> major, and that's what this thread is about. But even then, how much of that
> is there, compared to applications development?
> 
> Matt

Essentially, I agree.  The dot com boom was largely web-centric, and web
programming tools rapidly exploded away from the early Perl and shell
script hacks on simple HTML.  Certainly programming the early web didn't
require a preparation in CS, nor did it especially benefit from it.
However, the later web programming tools and the three tier web-centric
application model is little different from programming projects of old
in terms of managing complexity.  As such, a CS degree is perhaps more
appropriate prep for that kind of work, but I'd agree that it's still
hardly ideal.  What's more, just as CS departments fail to teach
individual programming languages (perhaps rightly so), they almost
entirely ignore web technologies.  Given the increasing prevalence of
web-based computing over traditional, I think weblessness is another
major omission in CS curricula.  The web is a new model for computing
and IMHO, CS is well behind the curve on that too.

Is MIS the right preparation for building web-based apps?  I guess I'd
have to say yes.  Probably MIS is better preparation all 'round to be a
modern programmer.  That's not to say that I would look only to MIS
programs if I were an employer -- I think MIS is still unable to attract
the brightest students or delve as deeply as it should into theory or
technology.  But I think the skill set emphasized in MIS programs is
significantly more relevant in serving the needs of commercial software
development than is CS.

If MIS programs would place a greater emphasize on:

- software metrics
- software engineering
- the use of feedback in optimizing software eng. practices
- algorithms, discrete math, and a wee bit of theory

Then I'd be willing to say that CS would be inferior to MIS++ for almost
all work in commercial software.

    Randy

-- 
Randy Crawford   http://www.ruf.rice.edu/~rand   rand AT rice DOT edu

While we're on the discussion of Computer Science, what do you think of
this? It's an online degree offered by Florida State University.
http://online.fsu.edu/student/degree/plan/roadmap/undergr/cs.html

Do you know of anybody that's done this?

See, if I take that job at that wireless ISP company, and I still wanted to
do CS, then that would be my only option. Otherwise it would be a 40 mile
drive through rush hour traffic, to go to USF in Tampa.

Matt

"Randy" <joe@burgershack.com> wrote in message
news:MtRoe.27069$j51.11277@tornado.texas.rr.com...
> Gregory L. Hansen wrote:
> > I've been seeing discussions here and elsewhere about computer science
> > programs that don't teach software engineering.  Software engineering
> > clearly has a practical role since people are writing software all over
> > the place.  But how does computer science fit into it?  Is that one of
> > those things whose primary product is scholarly articles, or does it do
> > much to inform the typical maker of software?  Do programmers find
> > themselves well served by their CSCI degree, or do they tend to have to
> > learn a lot of stuff that just wasn't taught in school?
>
> Computer science (as it's taught and researched in academia) has
> almost nothing to do with the development of software solutions.  CS
> focuses on individual computational techniques, but does not integrate
> these into a whole nor does it deal in the pragmatics of using
> software to solve user needs.  CS curricula use software to solve
> homework problems, not user problems.
>
> This is partly because almost all professors have never been in the
> trenches, producing code under a deadline, with a customer 1) who
> doesn't know what's possible or what is needed, 2) who needs the
> software now, 3) who wants to pay as little as possible for it.
> Making architectural tradeoffs under such circumstances is an entirely
> different enterprise from assessing an algorithm's asymptotic
> complexity.  The latter is still valuable but the former is essential:
> it's the life blood of business.  But on the radar screen of CS
> academics, the needs of business or the user don't rate even a tiny
> dot.  That's why courses in software engineering, application domains,
> and "designing for the user" are rare as hen's teeth in CS.
>
> IMHO, CS is good preparation for:
> - teaching CS
> - advancing our understanding of the principles of computing
> - speeding up software, networks, or microarchitecture
> - building new software tools (compilers, O/Ses, databases, etc)
> - implementing difficult software components (drivers, kernels, HPC,
>    database engines, compilers, network stacks, etc)
>
> IMHO, CS is poor preparation for:
> - developing software in teams, on time, that works
> - analyzing the need for a given software solution, designing the
>    software, testing it, or learning from your mistakes and building
>    better software in the future
> - managing the lifecycle of a program (including documentation)
> - understanding how software is used (by business or the individual)
> - engineering a software solution as a collection of cost tradeoffs
> - debugging existing code and reducing bugs in future code
> - understanding the user's problem space or mapping software to the
>    problem space
>
> I've always been amazed that NOBODY in academia has laid claim to the
> agenda of experimental software engineering.  There is a CRYING need
> to assess the relative success of different programming models, much
> less quantitatively assessing analysis models, design processes,
> implementation tradeoffs, testing practices, etc.  Oddly, NOBODY in
> academia does this sort of thing.  Even when a department comes along
> that calls itself "software engineering" purportedly to undertake
> these much needed investigations, instead they seem fascinated with
> the theory of software development, as an abstract model of how
> software MIGHT be built, but not the concrete evaluation of what works
> and what doesn't.
>
> I understand that like experimental/quantitative economics, taking a
> practical approach to software is a lot more work than is proposing
> philosophy or theory.  But practice is a hell of a lot more useful too.
>
>      Randy
>
> -- 
> Randy Crawford   http://www.ruf.rice.edu/~rand   rand AT rice DOT edu

Gregory L. Hansen wrote:
> In article <1118037562.171515.250880@o13g2000cwo.googlegroups.com>,
>  <spinoza1111@yahoo.com> wrote:
> >
> >
> >Gregory L. Hansen wrote:
> >> I've been seeing discussions here and elsewhere about computer science
> >> programs that don't teach software engineering.  Software engineering
> >> clearly has a practical role since people are writing software all over
> >> the place.  But how does computer science fit into it?  Is that one of
> >> those things whose primary product is scholarly articles, or does it do
> >> much to inform the typical maker of software?  Do programmers find
> >> themselves well served by their CSCI degree, or do they tend to have to
> >> learn a lot of stuff that just wasn't taught in school?
> >
> >Considered as "success in implementing software", "software
> >engineering" has little to say because in fact there is little success
> >(with an 80% failure rate according to some sources).
>
> That seems like something that should be aggressively addressed.

It is not insofar as part of the role of an enterprise system is to
manufacture consent, and the user of an ATM can be trusted to accept,
given the authority of enterprise systems, that 100 isn't divisible by
20.

*Qua* being a CEO, the CEO isn't interested in software correctness for
the same reason he regards Sarbanes-Oxley conformance as an annoyance
and pays lawyers to determine minimal taxes.


>
> >
> >If the SE student desires his personal success he may as well learn
> >that in a laissez-faire economy nobody has any interest in teaching him
> >how to steal their ricebowl and that in this regard much (not all) of
> >software engineering is like learning options, puts and calls. The
> >personally successful are too busy making money.
>
> Electrical engineers, mechanical engineers, civil engineers, and others,
> learn their craft in school.  They learn how to make bridges that don't
> fail, radios that don't change stations unexpectedly-- they learn how to
> design.  They study methods of quality assurance.  They have
> state-governed certifications, and it's required that a PE sign off on a
> project like a bridge design.  But software engineers should be dumped
> into the piranha tank to figure it out on their own?
>
Yes, why is that so? It's because insofar as software is rhetorical and
manufactures consent, it doesn't have to be correct or even "work".

> From your opinion it would seem that software engineering can hardly be
> called engineering at all!  It's not up to the standards of any other
> engineering field.  At least not in the US.  By contrast, India has been
> working hard to import IT work.  That includes an intensive effort on
> quality, they make it one of their major selling points, and CMM 5 shops
> are the norm in that country.
>
The problem here is that at the point of use the quality software can
be misused.

> >
> >Good programmers on the other hand are precisely who use computer
> >science. Period. They use it to the point of resistance to that part of
> >"software engineering" which is constituted in learning subservience.
>
> My question was triggered in part by the gentleman who had been through a
> computer science program and still wasn't sure what OOP is.  Elsewhere
> someone mentioned a fellow who had completed a computer science degree
> without writing any code at all.  That didn't seem like adequate
> preparation when the end result of a computer science degree so often is
> someone that writes software.  But all the employers still want to see the
> bachelor's degree.
>
My experience "offshore" is that the same conditions obtain, and CS
education as a result is becoming sharply two-tier in the US model.

In the US model, students from middle class and poor backgrounds are as
a rule excluded from the "top" schools (with scholarships and
Affirmative Action papering over the realities).

In computer science in the "top" schools, you can be assured that
graduates will have not only "programmed". They will have written
serious compilers and real operating system kernels.

I took compiler development at DePaul (a second tier school) in 1976
and had to write a paper compiler. I started Dave Hansen's class in
compiler development at Princeton but I had to drop out since I was
working full time for Princeton and consulting on the side. Professor
Hansen wanted us to write a real compiler. Having done so already I
would have been delighted to do so but couldn't justify the time
investment.

At DePaul I'd used the first edition of the textbook Hansen used (the
1985 Dragon book) but overall, Hansen's expectations were much higher
than at DePaul. It would have been far better for me to attend
Princeton in 1976 (yeah, right) and as it happened this was the opinion
of my faculty adviser at DePaul.

He was the department chair and my professor in computer architecture
and compilers and he felt I was simultaneously overqualified for his
program, and so saddled already with family responsibilities that I
might not be able to complete it. He was right, and I had to drop out
close to graduation.

My experience is the norm. People who have potential for academic
success are always hosed out of academia "unfairly" which is why I
believe that college should be open to all, conditional on military or
national service. The sad thing is that they then sit around ever after
in sour-grapes mode and dismiss "computer science" as
"irrevelant"...while fortunes are made by Princeton graduates, who, you
may be assured, use cs in "rocket science" finance and dozens of other
fields.

Whereas the phenomena you describe happen down in the lower levels
where it was my discovery that computational realities are deliberately
obscured in a misunderstood "pragmatism".

I've worked at Princeton, taught at Roosevelt and DeVry, and worked in
Fiji and China so I know whereof I speak.

Princeton doesn't teach a class in C despite the fact that C was
invented there and at Bell Labs. Instead, the student is expected to
know it upon matriculation into the cs major: as I result I taught
miniclasses in C at Princeton.

Whereas lower-level institutions make a great to-do about teaching the
latest language, wasting untold resources for example in the 1980s
teaching Pascal.

Computer science seems "irrevelant" to business types in MIS because
(to be quite brutal) of deficiencies in their education where they
never had the opportunity to look up from the telescope and apprehend
the stars.

To learn what was behind the claptrap.

"Software engineering" is their name for something that doesn't exist.

Now, you don't have to go to a top school to learn CS. Larry Ellison
hosed out of the University of Illinois but in their infamous Fortran
class of the late 1960s he learned that despite his Attention Deficit
Disorder he could get quick and useful results by concentrating on
Fortran programming for short and intense periods of time.

This was in Chicago of the late 1960s in which the lower middle class
was being slowly screwed out of decent jobs in the trades and being
told to blame black folks, and ADD, in my experience, was quite common
in the schools of that city, then and now a behavioral sink. At the
same time Ellison made his discovery I found out the same thing about
myself courtesy of an aging 1401 mainframe a mile away from Circle
Campus.

The 1401 didn't care that I had long hair, looked about 12 years old at
the age of 20, and was always horny. Instead, if I focused sharply I
could make it act the the computers I'd seen in 2001. This was very
cool. It was even cooler when guys in suits with heavy glasses, who
looked like Nelson Rockefeller or my father, congratulated me for
getting them their reports.

But instead of getting a job in a bank in the loop, and whining ever
after that computer science had nothing to do with his trade, it seems
Ellison escaped to California in pursuit of sex, drugs and rock and
roll, and in 1976 he and I learned more or less by accident about
relational data base.

At the time it was actually believed courtesy of a defunct organization
called Codasyl that companies should decide, once and for all, that to
get to a file you'd have to navigate a fixed path through a tree, which
was bullshit even then. As computer scientists, Codd and Date asked
"what if" you could get what users "really wanted" which was a flat
presentation of information in a table.

Data processors of that era believed that such tables had to be
predesigned but Codd and Date showed that instead of existing from day
one, they were an instance of a more general concept that of the
relation, and that relations could be expressed as the product of a
calculus.

This wasn't "software engineering". It was computer science, even
though it was conducted by IBM researchers...who at the time were not
subject to Lou Gerstner's abuse.

To which the usual reaction in the Loop was "dis is too complicated and
is some professor's airy fairy garbage: all we need is hierarchical
data bases in IMS because I knows IMS and CICS real good".

Whereas Larry built Oracle and sold seats to the CIA, which gave him
cash flow. The rest is history.

My conclusion? Don't listen to the guys in the neighborhood, whether
that's the physical neighborhood of Chicago or dis newsgroup which is
fulla thugs.

Being guys, they will ALWAYS tell you that "what I don't know is
useless" and will consider themselves ill-served by teachers that
actually make them THINK, for example about what would happen IF we
could get a normalized flat file on demand if we mastered a simple
calculus.

I have discovered that in China, there are ALSO guys in the
neighborhood who sit around and say they can write software by magic.
Fortunately, as in America there are also homeboys who don't listen to
these gangstas and spend half their income on international editions of
Cormen's Algorithms.

For more information on Ellison see the book "Softwar: an Intimate
Portrait of Larry Ellison and Oracle", Matthew Symonds.

Oracle is founded not on "software engineering" but on the computer
science discovery of relational data base. As I've shown in this
thread, cs has made real progress while year after year, "software
engineers" have tried without success to make things out of people and
to enable people who can't program to uh program.
>
> --
> "The preferred method of entering a building is to use a tank main gun
> round, direct fire artillery round, or TOW, Dragon, or Hellfire missile to
> clear the first room." -- THE RANGER HANDBOOK U.S. Army, 1992

Looks pretty solid, Matt. The trouble is that as soon as employers
discover that a degree is by correspondence or online, they go,
"yecchhhh, by correspondence or online, what's with this guy, is he a
recovering dope addict or felon?"

My take is that this psychology is rampant in Florida because in fact
wealth and "respectability" in Florida are so cheek by jowl with
various forms of business and common criminality. For example, Florida
made as you know a great to-do about excluding felons who served their
time from voting in the 2000 election.

My advice is to complete the program. Give it all you've got. Then when
asked for your degree, write it down simply, with no implication that
it was online. Don't ever volunteer this information.

Education should be education for freedom and available to all. But in
America it has long been perverted to preselect people worthy of
advancement (the Fortunate Son, like George Bush) from the rest of us
who struggle at night or online.

The program to which you point does seem to contain all the classes
required for the traditional ACM (Association for Computing Machinery)
certification. Furthermore, having taught at DeVry, I can assure you
that the profs work their tails off. This is because at DeVry we
adjuncts were "under the gun" to set high expectations lest the school
acquire diploma-mill status.

Because my "office" was my car, and because in Chicago the police had a
bad habit of towing my car in River North when I would merely park it
in front of the Greek church seen in My Big Fat Greek Wedding (because
you never know when the Greeks would want to have a big fat wedding), I
set up a data base on my laptop to track student assignments when
handed in, as well as detailed (>255 byte) descriptions of student
progress in classes with 60+ enrolled.

I worked about 40 hours a week unpaid prep and grading time, in fact. I
am sure the profs in the program you are thinking of do the same. At
least, I hope so.



Matt wrote:
> While we're on the discussion of Computer Science, what do you think of
> this? It's an online degree offered by Florida State University.
> http://online.fsu.edu/student/degree/plan/roadmap/undergr/cs.html
>
> Do you know of anybody that's done this?
>
> See, if I take that job at that wireless ISP company, and I still wanted to
> do CS, then that would be my only option. Otherwise it would be a 40 mile
> drive through rush hour traffic, to go to USF in Tampa.
>
> Matt
>
> "Randy" <joe@burgershack.com> wrote in message
> news:MtRoe.27069$j51.11277@tornado.texas.rr.com...
> > Gregory L. Hansen wrote:
> > > I've been seeing discussions here and elsewhere about computer science
> > > programs that don't teach software engineering.  Software engineering
> > > clearly has a practical role since people are writing software all over
> > > the place.  But how does computer science fit into it?  Is that one of
> > > those things whose primary product is scholarly articles, or does it do
> > > much to inform the typical maker of software?  Do programmers find
> > > themselves well served by their CSCI degree, or do they tend to have to
> > > learn a lot of stuff that just wasn't taught in school?
> >
> > Computer science (as it's taught and researched in academia) has
> > almost nothing to do with the development of software solutions.  CS
> > focuses on individual computational techniques, but does not integrate
> > these into a whole nor does it deal in the pragmatics of using
> > software to solve user needs.  CS curricula use software to solve
> > homework problems, not user problems.
> >
> > This is partly because almost all professors have never been in the
> > trenches, producing code under a deadline, with a customer 1) who
> > doesn't know what's possible or what is needed, 2) who needs the
> > software now, 3) who wants to pay as little as possible for it.
> > Making architectural tradeoffs under such circumstances is an entirely
> > different enterprise from assessing an algorithm's asymptotic
> > complexity.  The latter is still valuable but the former is essential:
> > it's the life blood of business.  But on the radar screen of CS
> > academics, the needs of business or the user don't rate even a tiny
> > dot.  That's why courses in software engineering, application domains,
> > and "designing for the user" are rare as hen's teeth in CS.
> >
> > IMHO, CS is good preparation for:
> > - teaching CS
> > - advancing our understanding of the principles of computing
> > - speeding up software, networks, or microarchitecture
> > - building new software tools (compilers, O/Ses, databases, etc)
> > - implementing difficult software components (drivers, kernels, HPC,
> >    database engines, compilers, network stacks, etc)
> >
> > IMHO, CS is poor preparation for:
> > - developing software in teams, on time, that works
> > - analyzing the need for a given software solution, designing the
> >    software, testing it, or learning from your mistakes and building
> >    better software in the future
> > - managing the lifecycle of a program (including documentation)
> > - understanding how software is used (by business or the individual)
> > - engineering a software solution as a collection of cost tradeoffs
> > - debugging existing code and reducing bugs in future code
> > - understanding the user's problem space or mapping software to the
> >    problem space
> >
> > I've always been amazed that NOBODY in academia has laid claim to the
> > agenda of experimental software engineering.  There is a CRYING need
> > to assess the relative success of different programming models, much
> > less quantitatively assessing analysis models, design processes,
> > implementation tradeoffs, testing practices, etc.  Oddly, NOBODY in
> > academia does this sort of thing.  Even when a department comes along
> > that calls itself "software engineering" purportedly to undertake
> > these much needed investigations, instead they seem fascinated with
> > the theory of software development, as an abstract model of how
> > software MIGHT be built, but not the concrete evaluation of what works
> > and what doesn't.
> >
> > I understand that like experimental/quantitative economics, taking a
> > practical approach to software is a lot more work than is proposing
> > philosophy or theory.  But practice is a hell of a lot more useful too.
> >
> >      Randy
> >
> > --
> > Randy Crawford   http://www.ruf.rice.edu/~rand   rand AT rice DOT edu

In article <1118201840.505931.284220@g43g2000cwa.googlegroups.com>,
 <spinoza1111@yahoo.com> wrote:
>Looks pretty solid, Matt. The trouble is that as soon as employers
>discover that a degree is by correspondence or online, they go,
>"yecchhhh, by correspondence or online, what's with this guy, is he a
>recovering dope addict or felon?"

Just an idea, I don't know if it's a good one, but could someone do most 
of their work by correspondence or online, then transfer to a traditional 
school for the last year or so?  It's common already to start one's 
education at a local community college, then transfer credits to a 
university.



-- 
"A nice adaptation of conditions will make almost any hypothesis agree
with the phenomena.  This will please the imagination but does not advance
our knowledge." -- J. Black, 1803.