
Stroustrup: What Should We Teach New Software Developers? - zzygan
http://cacm.acm.org/magazines/2010/1/55760-what-should-we-teach-new-software-developers-why/fulltext
======
owinebarger
I can't believe no one's mentioned:

    
    
      Computer science is no more about computers than astronomy is about telescopes.
      -- Edsger Dijkstra
    

Contrary to the beliefs or desires of some, colleges and universities are not
vocational training institutions. In the actuarial world, there is a rigorous
credentialing process involving a series of exams usually taking a minimum of
4.5 years to complete. However, even with all of the exams passed, without
experience you'd be put into an entry-level position. If your experience is in
one field of insurance and you want to get into another, that experience won't
count for much in the new field and you'll probably be starting near entry-
level again.

That's for good reason. Academia is for teaching you known facts and theories,
and how to think for yourself. Experience in an industry teaches you how to do
a particular type of work so that other people are willing to give you money
in exchange for your labor. These are inherently different activities, though
the former can weed out some inappropriate candidates for the latter.

~~~
jbellis
The purists complaining that CS isn't about programming are correct but
misguided: the vast majority of CS majors don't _want_ to study "real,"
abstract CS.

IMO the right thing is to offer degrees in Software Development, which would
include some classic CS curriculum but by no means all, and we could have
discussions about the right way to teach programming without people getting
bent out of shape that Programming Is Not CS.

~~~
baddox
I'm a CS major, and while I admittedly wasn't fully aware of what "computer
science" entailed, I knew enough to know I wanted to study it. And I don't
regret it.

~~~
Travis
Yeah, same here, except I graduated in 2004. I took CS from an engineering
school, so I had a little less theoretical background (that was replaced with
EE / CompE basics). But I agree -- I had exposure to big-O in h.s., but didn't
realize that CS would involve so little programming (I probably wrote under 2k
lines of code in 4 years, to be honest... but I was a slacker too ;) ).

~~~
andreyf
IMO, if one is to choose between theoretical background and EE/CompE, the
latter is significantly more valuable. Of course, both are important.

------
btilly
What he says sounds good in the abstract, but I worry about how it will be
implemented. For instance he raises the issue of licensing people to practice
computer science. However as he acknowledges that it is difficult to even
identify who should be in charge of deciding what should be _tested_ for such
a license.

And that is a big issue. A license created to meet the needs of business 40
years ago would certainly have required learning COBOL. A license created 20
years ago would have no relevance to web development. One created today would
likely be geared towards the needs of large organizations with large code
bases - which would put most agile development techniques, languages, and
practices off the table.

For better or worse the programming world has diverse communities with rapidly
changing, diverse needs, and no possible solution has any hope of fitting all
of them.

~~~
moron4hire
Licensing is an afterthought to his main thesis. His main point is that we
have to remove the disconnect between industry and academia. Both parties take
pride in being completely separate from one another. This has to end, and that
is a cultural change, something that is completely within the realm of doing
in less than 10 years.

As for the relevancy of licensing, I think there is a certain degree to which
one could start certifying software engineers on a project management
perspective, because the principals of how one approaches a project and brings
it to completion aren't that different from any other project in any other
industry. If you're running your project correctly, programming is maybe 10%
of the project. That other 90% has a lot to learn from the rest of the
industrial fields to catch up and start adopting standard practices.

A user's requirements are going to be the same no matter what programming
language you use. The way you test the software is going to be the same no
matter what programming language you use. Within a specific programming
paradigm, how you build the software is a shear matter of syntax, all the
parts are going to have to be the same. Just as you can have a suspension
bridge versus a stone bridge, I think you could study object oriented
programming versus functional programming, and I don't see any reason why we
shouldn't expect professional, licensed software developers to know both.

COBOL, C, C#, Clojure, C-whatever-next, it doesn't matter. Wood, stone, and
iron. The principles haven't changed much at all.

~~~
btilly
_I think there is a certain degree to which one could start certifying
software engineers on a project management perspective, because the principals
of how one approaches a project and brings it to completion aren't that
different from any other project in any other industry._

Huh?

Project management on a website that has an incremental 1 week release cycle
has no relationship to project management of an internal database upgrade that
is planned for 6 months or project management for developing a shrink wrapped
game over 2 years.

The problems, documents, workflow, problems, types of people you need
involved, etc are radically different in these three cases.

 _A user's requirements are going to be the same no matter what programming
language you use. The way you test the software is going to be the same no
matter what programming language you use. Within a specific programming
paradigm, how you build the software is a shear matter of syntax, all the
parts are going to have to be the same._

I disbelieve.

I've been in a situation where I was creating a reporting system, and was
sitting in a group of people building a website. There was absolutely no
similarity in requirements, testing, rollout procedures, and turnaround
expectations between me and the other developers. This despite the fact that
we were working in the same organization, on projects specified by the same
product managers!

As for a specific programming paradigm comment, the statement seems to me to
be vacuously true because you define "paradigm" to include the internal
structure of the software, or else false. Because I've seen many cases where
two people deliver essentially the same functionality using the same basic
toolkit, but the internal organization, pieces, etc are completely different.

 _COBOL, C, C#, Clojure, C-whatever-next, it doesn't matter. Wood, stone, and
iron. The principles haven't changed much at all._

Huh? COBOL doesn't even have recursion. C has function pointers but no
closures. C# has closures but no Lisp style macros. Clojure has all of the
above. The capabilities of the languages are different, and therefore the
proper design and structure of software is as well.

Also where principles have not changed, people's understanding of them may.
For instance take test driven development. It isn't new - when Larry Wall
delivered Perl 1 in the mid-80s it came with a reasonably complete test suite.
When CPAN was founded in the mid-90s the whole perl Makefile.pl, make, make
test, make install routine was already standard. And the result was that Perl
got a good name for being portable in practice.

However as recently as a decade ago you'd have been hard pressed to find many
advocating a test driven style of development. Problems existed that it would
work well for. Useful enough tools existed for people to take advantage of
them. But there wasn't wide spread acceptance of that knowledge.

Today if you are a programmer and _don't_ know the basics of unit testing, you
need some remedial re-education. And a lot of organizations don't use it.

In short unit testing today is where source control was in the late 90s which
is where structured programming was in the 80s. It is a good idea. It is
widely recognized to be a good idea. But it is a good idea that is more
honored by the breach than the observance in your average programming shop.

~~~
stonemetal
_The problems, documents, workflow, problems, types of people you need
involved, etc are radically different in these three cases._

How so? In the web site case I need a person who can code and person to do
art/design. In the instance of a game guess what I need a person who can code
and someone to take care of the art and design. The only real difference seems
to be a matter of scale. Every project in the software development world
consists of two things content and code.

 _The capabilities of the languages are different, and therefore the proper
design and structure of software is as well._ Hey guess what the properties of
wood iron and stone are just as different and require different designs or do
you think the sears tower could have been made of wood with out a change in
its design?

~~~
btilly
You _really_ think that the only thing you need to produce a shrink wrapped
game that is in production for 2 years is someone to code and someone to take
care of art and design? And you really don't understand why I would say that
project management on that project is very different than project management
on a website that delivers incremental revisions every week?

Sorry, but you clearly have some things to learn. Go pick up
[http://www.amazon.com/Software-Project-Survival-Guide-
Practi...](http://www.amazon.com/Software-Project-Survival-Guide-
Practices/dp/1572316217) and learn what a stand alone project on the scale of
that game needs to do just to have a reasonable chance of success. Virtually
none of that book applies to the incrementally developed website.

Oh, and don't forget that the game has no chance of success without a lot of
non-software work such as licensing and marketing.

------
stonemetal
The only problem that he actually mentions is:

 _Also, many students fail to connect what they learn in one class to what
they learn in another. Thus, we often see students with high grades in
algorithms, data structures, and software engineering who nevertheless hack
solutions in an operating systems class with total disregard for data
structures, algorithms, and the structure of the software._

That is to say pass fail grading of programs, grading should be similar to an
English class how you express it is just as important as what you express.

~~~
caryme
I wholeheartedly agree with you on the grading aspect. Even in classes where
professors or TAs effectively grade and comment the code, I think most
students have a tendency to see the grade they received and ignore the
professor's feedback. The program worked, they got the grade, onto the next
assignment.

I had two classes this past quarter taught by a professor with a very
different grading system. He used a program he wrote called the "code critic"
to have us submit exercises into his grading queue. Only working code could be
submitted and we could only have three assignments in the queue at once. He
would then use his program to return the code with criticism added on any
lines not to his liking and mark the assignment as "Not done," "Almost done,"
or "Done." If he didn't mark it done, we had to fix the code in response to
criticism. These criticisms were very picky, even sometimes dealing with the
naming of functions and variables.

At the end of the quarter we were graded on how many assignments we were
completed, and _how much we grew as programmers_. If our assignments at the
end of the quarter did not require any resubmissions, this was reflected in
our grade.

I think this method was an extremely effective alternative to traditional
grading. I learned more about programming and style in both C++ and Lisp in
these two classes than I have in any other classes to date.

~~~
andreyf
_even sometimes dealing with the naming of functions and variables_

Ugh. Asking a CS major to adhere to naming conventions is like asking an art
major to color within the lines. It has very little to do with computing.

~~~
scott_s
Your analogy does not make sense to me. The professor clearly wanted his
students to become not just better at hacking together solutions, but
presenting readable, consistent code. This is a noble goal, and you're correct
it has little to do with computing. It has to do with communicating to other
people what you have done.

~~~
andreyf
Good point the analogy definitely doesn't completely account for the adjacent
field of software engineering, where coding styles are certainly important. I
guess that's mostly because artists rarely work in large groups, and when they
do, I'd imagine the work is mostly parallelize-able: several people don't need
to go through the details of any single piece of work.

~~~
stonemetal
Animation. Easy to work in parallel but output is very constrained
stylistically. Multiple author books tend to have stylistic constraints as
well otherwise the book suffers from an uneven feeling.

------
ahlatimer
I find it interesting the he suggests _requiring_ a minor in another field. I
largely agree with this, but at my school, you can't get a minor if you're a
CS major. For instance, by the time I graduate, I will have the required
credits for a minor in math. That minor won't be recognized by the university,
and I can only say that I've completed the courses for a math minor without
actually earning one.

The same is true for double-majoring. I have a friend that wanted to double
major in CS and linguistics to do AI, but he was told that he couldn't.
Instead, he has to stick around for an extra year to get two distinct degrees.
He's had to waste time because some of the courses he needed to take required
you to have declared a major in that field.

This is from a school that probably has a more vocationally applied view of a
CS degree. We are, for instance, required to take two semesters of software
engineering. They're obviously interested in giving a student an education
that will be useful in the industry, but they also have inane rules like the
one described above.

------
qhoxie
It seems unproductive to respond to this discussing how difficult it would be
to fix/implement. I think Stroustrup probably knows that better than most
anyone else, given, as he noted, his unique perspective.

What is productive is gaining acknowledgement that this problem exists, as
that is the (cliche) first step. I believe this is a serious problem. I've
seen the sub-par software, code, and the people writing it for years - it's
not changing through academia or industry. Both sides continue to address
their needs independent of one another, and that is far from optimal.

Many of the finest professionals I have met in the industry cannot say more
than a few positive words about their CS programs. Most of them will also
recommend _against_ pursuing the degree if you actually want to excel with
code.

Agreed, the fix(es) will not be an easy find, but it is far from impossible.
This needs to be taken care of - I'd love to be able to tell friends that want
to be a good coder that they can go to school for that.

------
helwr
This reminds me of Andrei Sakharov, the father of soviet nuclear bomb who
became an anti-nuclear activist later in his life. OOP makes writing bloatware
so easy, you don't need to think, just reuse someone else's classes, and this
is what they teach in CS 101. Ironically the author is one of the creators of
the problem.

------
bokchoi
I don't think these problems are unique to computer science.

~~~
moron4hire
No, they aren't. What is unique though is that we have such a complete
reliance on software without any sense of how to do it well. We know how to
build skyscrapers without them falling down when the first real "user" steps
through the front door. We don't know any sort of thing for software
development.

~~~
randliu
We can't afford a single skyscraper collapse, but we can usually afford to use
bad software.

The article sounds like Dijkstra in 1988. My bet is another 22 years won't
change anything.

~~~
rbranson
...and, let's face it, the relative complexity of a skyscraper compared to a
computer software program, given equal cost, is very, very low. A skyscraper
costs hundreds of millions to construct. An equally costly software project
would be something like the entire lifespan of the .NET Framework including
the CLR, Standard Library, C#, VB.NET, Silverlight, all of the "Enterprise"
features, etc.

Also, software isn't really construction. It's built by the people who design
it, for the most part. Imagine a skyscraper (or car, bridge, etc) built
entirely by engineers. Yikes.

------
bcl
You are never going to be able to license software developers as a whole.
Maybe some small subset, but the barriers to entry are just too low for a
widespread licensing system to be imposed. Software is too fluid for some
standards body to say 'you must know XYZ', we are constantly inventing new and
better ways to write software.

Also remember, this is the guy who gave the world C++

~~~
moron4hire
"We are constantly inventing new and better ways to write software". Name one
"new" thing in the last 10 years. Whatever you come up with, I bet there is a
reasonable analog from 20 or even 30 years ago. We know practically _nothing_
concrete about software development. Even the concepts of RAD and Agile which
are so popular today have been around for 30 years.

"Also remember, this is the guy who gave the world C++". Yes, one of the most
popular object oriented languages that is still suitable for systems
programming. What of it? For all the complaining about C++ as an ideal tool,
it's been incredibly successful as a practical tool. I don't use it, but I
have a lot of respect for what it has done.

~~~
spc476
I currently make my living with Linux, and yet I get this nagging feeling that
if programmers were licensed, I would have to have learned any number of
Microsoft technologies (OLE, COM, DCOM, ActiveX, .Net) depending on _when_ I
got licensed.

I entered college in 1987. Windows 2.x had just come out (I think)---OS/2
wasn't even being designed as of yet. The Intel 386 had just come out, and
major application design in PCs in assembly had just passed in favor of C or
Pascal. I couldn't even have comprehended my job today (programming wise---web
based applications written in PHP) back then.

Yes, there hasn't really been anything "new" in the past 20 years (except
maybe for ubiquitous networking) but the details sure have changed a lot.

~~~
moron4hire
Whether or not an appropriate, relevant licensing scheme _would_ be developed
is a different issue from whether or not it _could_ be developed.

As for the details changing, yes, _programming_ has changed a lot, but
programming is such a small part of any project.

------
numeromancer
Bang! Pow! Super-Stroustrup defeats an entire platoon of evil Straw-Men,
single-handed!

------
Venthor
I think this article was point on. I wish more people in our industry
(software developers) understood and tried to fix these problems.

------
giardini
Surely there is a better source of "What Should We Teach..." than the fellow
who pulled C++ out of Pandora's box?

~~~
dinkumthinkum
That's sort of ad hominem. Would DHH be a better choice? I mean honestly, I
find it hard to take seriously that Bjarne Stroustrup is not credentialed to
be a voice in this discussion.

------
billswift
_Another CS professor: "I never code."_

Sort of like a linguistics professor saying "I never talk".

~~~
durin42
Really? How so?

Linguistics is the study of language, but CS at its core is the study of
algorithms and theory. A CS prof never coding is more akin to a Physics
professor never designing his own bridge. Sure, he technically _could_ if he
wanted to, but that's probably still better left to the engineers.

Dijkstra said (rightly, IMO) "Computer science is no more about computers than
astronomy is about telescopes." I think a corollary to that is that it's also
not about programming/coding per se, but the theoretical study of techniques
we use when building programs.

~~~
dinkumthinkum
I think that's just going too far. I think the analogy to a Physics professor
never building a bridge is a bit silly. You might as well say a "Physics
professor that never swims or enjoys a warm breeze on a hot summer's day."

A Computer Science theoretician's work is somewhat more closely tied to
programming. I mean, let's be serious.

~~~
ephermata
What do you have in mind when you say "computer science theoretician" ? Do you
mean someone who publishes in the ACM Symposium on the Theory of Computing or
do you mean something else?

