This thread on Hacker News terrifies me

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Aug 31 23:20:08 UTC 2018


On Fri, Aug 31, 2018 at 04:45:57PM -0600, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, August 31, 2018 4:23:09 PM MDT Walter Bright via Digitalmars-d 
> wrote:
[...]
> > That won't fix anything, because there is NO conventional wisdom in
> > software engineering for how to deal with program bugs. I suspect I
> > am the first to try to apply principles from aerospace to general
> > engineering (including software).
> >
> > For example, in any CS program, are there any courses at all about
> > this?
> 
> There are probably some somewhere, but most CS programs really aren't
> about writing good software or even being a software engineer. Some
> definitely try to bring some focus on that, but it's far, far more
> common that the focus is on computer science concepts and not on
> software engineering. A good CS program gives you a lot of theory, but
> they're rarely big on the practical side of things.
[...]
> It's often pretty scary how poor the average programer is, and in my
> experience, when trying to hire someone, you can end up going through
> a lot of really bad candidates before finding someone even passable
> let alone good.
[...]

The problem is that there is a disconnect between academia and the
industry.

The goal in academia is to produce new research, to find ground-breaking
new theories that bring a lot of recognition and fame to the institution
when published. It's the research that will bring in the grants and
enable the institution to continue existing. As a result, there is heavy
focus on the theoretical concepts, which are the basis for further
research, rather than pragmatic tedium like how to debug a program.

The goal in the industry is to produce working software. The industry
doesn't really care if you discovered an amazing new way of thinking
about software; they want to actually produce software that can be
shipped to the customer, even if it isn't using the latest and greatest
theoretical concepts.  So they don't really care how good a grasp you
have on computability theory, but they *do* care a lot that you know how
to debug a program so that it can be shipped on time. (They don't care
*how* you debug the program, just that you know how to to it, and do it
efficiently.)

A consequence of this disconnect is that the incentives are set up all
wrong.  Professors are paid to publish research papers, not to teach
students.  Teaching is often viewed as an undesired additional burden
you're obligated to carry out, a chore that you just want to get over
with in the fastest, easiest possible way, so that you can go back to
doing research.  After all, it's the research that will win you the
grants, not the fact that you won teaching awards 3 years in a row, or
that your students wrote a glowing review of your lectures. So the
quality of teaching already suffers.

Then the course material itself is geared toward producing more
researchers, rather than industry workers.  After all, the institution
needs to replace aging and retiring faculty members in order to continue
existing.  To do that, it needs to produce students who can become
future researchers.  And since research depends on theory, theory is
emphasized, and pragmatism like debugging skills aren't really relevant.

On the other side of the disconnect, the industry expects that students
graduating from prestigious CS programs ought to know how to program.
The hiring manager sees a degree from MIT or Stanford and is immediately
impressed; but he doesn't have the technical expertise to realize what
that degree actually means: that the student excelled in the primarily
theory-focused program, which may or may not translate to practical
skills like programming and debugging ability that would make them
productive in the industry.  All the hiring manager knows is that
institution Y is renowned for their CS program, and therefore he gives
more weight to candidates who hold a degree from Y, even if that
actually doesn't guarantee that the candidate will be a good programmer.
As a result, the software department is filled up with people who are
good at theory, but whose practical programming skills can range
anywhere from passably good to practically non-existent.  And now these
people with wide-ranging programming abilities have to work together as
a team.

Is it any wonder at all that the quality of the resulting software is so
bad?


T

-- 
Amateurs built the Ark; professionals built the Titanic.


More information about the Digitalmars-d mailing list