identity crisis in computer science

Identity Crisis in Computer Science Education

A while back, the seeds of a post started rolling around in my head,

inspired by my lack of satisfaction with the preparation my education

provided me for a programming career. But I didn't quite know what I

thought. Then not long ago, Joel Spolsky presented a radical

repackaging of Computer Science degrees, supposedly geared toward

producing better programmers, and my thoughts started to gel.

I knew what my personal complaint was, and I knew that it was

connected to a larger problem with the state of computer science

education in general. But I didn't know exactly what the larger

problem was, let alone have any ideas worth sharing on what might be

done about it.

Now that seemingly the entire remainder of the blogosphere has weighed

in on this and related topics, I think I am finally ready to throw my

two cents in. I'm going to barrage you with links in the following

paragraphs, to ensure that I credit everyone I read who assisted me in

coming to my final conclusions. Feel free not to click through, but be

aware that they represent a rich cross-section of an important

discussion.

It took me several weeks to realize that what we have going on is

essentially a three-way tug of war from people in different regions of

the vast sphere of software development, who need very different

things out of their workers, and hence out of their education. Below I

will give a run-down of some of the claims made, expressing the

different forces pulling on CS graduates these days. You'll quickly

see it's no wonder that the schools are so confused....

The Artisan Programmer

Joel laments the uselessness of theory courses in computer science

curricula, saying "I remember the exact moment I vowed never to go to

graduate school" and then proceeding to recall a terrible experience

he had with a Dynamic Logic class. Jeff Atwood insists that real-world

development environments need to be in place and mandatory, including,

but not limited to, source control, bug tracking, deployment, and user

feedback. Then, as mentioned above, Joel proposes offering BFAs in

software development, to make darn well sure that none of the academic

(in the pejorative sense) theory stuff gets mixed in unnecessarily.

The upshot of most of these points are that computer science /

programming degrees should spend as much time as possible teaching

people what they need to know to go into a career in software

development, writing business software or software products.

The Computer Scientist

Brian Hurt comes in from another direction entirely, and in the

process makes some very good points about the true purpose of higher

education. He lays the blame for the flood of single-language

programmers entering the workforce at the feet of schools who do just

exactly what Joel and Jeff are asking for. He makes some great points.

And while he sounds more than a little reminiscent of the classic Joel

post about the perils of java schools, his argument is much more

thorough than just blaming the tools. Chris Cummer joins this party,

wishing that his theory foundations had been firmer, and making an

excellent analogy to the difference between someone who studies a

language, and someone who studies language. We also have the

respectable Raganwald, who although he has admirably pointed out good

points from all sides, doesn't shy from offering his opinion that

programmers ignore CS fundamentals at risk of their own career

advancement.

The Software Engineer

But thats not all. Several people have weighed in from yet another

direction. Robert Dewar and Edmond Schonberg wrote one of the posts

that started off this blog firestorm. Along with alluding to a similar

sentiment as Hurt and Cummer, they heavily criticize the state of

software engineering education for focusing too much on how to use

specific, limited tools, when there are more sophisticated ones

available. They claim understanding these will allow software

engineers to easily pick up the other tools that may come along and

direct them to appropriate purposes. Ravi Mohan stops short of calling

the education satisfactory, instead sensibly pointing out simply that

an engineer who doesn't use standard engineering tools such as system

modeling, isn't really an engineer. Mohan comes on a little too strong

for me in the comments, but the posts themselves (of which there are

also a precursor and a successor, and should soon be one more) are

worth reading. Like the others he makes valid points.

Resolving the Crisis

Mark Guzdial is one of the few people that really puts his finger near

the pressure point. Though maybe not near enough to feel the pulse

beneath it when he did so. At risk of quoting a little too heavily....

Rarely, and certainly not until the upper division courses, do we

emphasize creativity and novel problem-solving techniques. That

meshes with good engineering practice. That does not necessarily

mesh with good science practice.

Computer scientists do not need to write good, clean code. Science

is about critical and creative thinking. Have you ever read the

actual source code for great programs like Sketchpad, or Eliza, or

Smalltalk, or APL 360? The code that I have seen produced by

computational scientists and engineers tends to be short, without

comments, and is hard to read. In general, code that is about great

ideas is not typically neat and clean. Instead, the code for the

great programs and for solving scientific problems is brilliant.

Coders for software engineers need to write factory-quality

software. Brilliant code can be factory-quality. It does not have

to be though. Those are independent factors.

And there it is.... Different environments require different

mindsets/approaches/philosophies. Research requires one

mindset/philosophy of work, engineering requires another, and

in-the-trench-based programming requires yet a third.

When a person suffers from a personality fracture, the resolution is

often to merge the personalities by validating each as part of a

whole. Fortunately, since we are not dealing with a person, we have

the freedom to go another direction: make the split real and

permanent.

Associate of Science in Computer Programming

To fill Joel and Jeff's need, the student who wants to work in the

craft of software development / computer programming, who wants to be

an artisan, needs to have an appropriate degree. It needs to provide

them with an exposure to the generalized idea of the programming

platforms and tools that they will have to deal with for the rest of

their career. Lose the lambda calculus, compiler-writing projects,

etc. These things not necessary for them to get stuff done in the

trenches. But they do need to be exposed to the fundamental

generalities that pervade programming. And they need to be prepared to

learn at an accelerated rate while in the field. That just comes with

the territory. Focus on core programming skills like program analysis,

debugging, and test practices. Introduce industry-standard tools

(emphasizing generality and platform-independence) such as

source-control, bug tracking, etc.

I think a two-year associate degree is perfect for the code-monkeys

and business programmers that just love to dig in and mess around with

code, and don't want to concern themselves with the overarching

concerns. Especially with these jobs increasingly being pushed

offshore, computer science grads are rapidly being priced out of the

market. An associate degree is cheap enough to be worth the investment

for a lower-paying programming job. And it doesn't carry the overhead

of any unnecessary theoretical content that they may not be interested

in learning. It should be noted though that this type of programming

job enters the realm of the trades, with all the associated benefits

and drawbacks.

If you're looking for a more well-rounded individual capable of moving

up out of this position into a lead position, or even management, then

a 4-year bachelor of science (or Joel's BFA, but I tend not to think

so) may be a viable option as well.

Bachelor of Science in Computer Science

There's not much to say about this degree, because if you look at all

the schools that are famous for their CS degrees, this is pretty much

what you'll find. Lighter on general studies, heavy on theory, heavy

on math. Light on tools because the students will be expected to find

(or make) tools that work for them. Light on specific language

education because students will be expected to adapt to whatever

language is necessary for their problem domain.

This is a degree that will produce people primed for going on to

masters and doctorates. They will end up in research, "disruptive"

startups, or working on new languages, OSes, etc. This degree is

designed for people who want to work at the edge of things. Who want

to solve new problems and push the boundaries. They are people upon

whom will be placed the burden of pushing the state of knowledge in CS

into the next era.

Bachelor of Science in Software Engineering

I am hesitant to propose this degree, because I am not certain that

the practice of Software Engineering has evolved to the point where we

have 4 years worth of general knowledge that's worth teaching, and

that won't be out of style by the time the student's graduate.

It seems that some people, when they talk about Software Engineering,

are talking about architecture and design, and others are talking

about process, resource allocation, estimation, etc. To be frank, I

don't think the former qualifies as a true engineering discipline. At

least not yet. I don't know how much the modeling of programs that

Ravi Mohan talks about is going on out there in the industry. I

suspect that it happens more in the process of really big projects,

and maybe in digital security. The second type of engineering people

think of, however, I think is very similar to what we see in

manufacturing, with industrial and process engineers. These are people

who get an intimate knowledge of the domain, and then figure out ways

to get everything to run smoother, more efficiently, and producing

higher quality.

I can definitely see some education possibilities here, though I am

not sure myself how to fill out the whole degree. It should at least

encompass a good portion of the Associate of Science in Computer

Programming, because they need to understand the intricacies involved.

I can also see this degree teaching some of the more established

measurement and estimation techniques found among the industry's

established and experienced software project managers. Generally more

management-related topics such as resource allocation, planning,

product design, feature negotiation, etc. might fit in well here.

Different project processes, testing/QA models, and of course an

ability to keep up to date with technologies and platforms, are all

par for the course as it's all critical for making decisions in the

industry.

Conclusion

I really, honestly believe that Computer Science education as a whole

needs a makeover. It needs more structure, more integrity in the

vision of what each degree means, across schools. When someone has one

of these degrees, you need to be able to reliably assume they should

have learned certain things, regardless what school they went to. Many

of the degrees currently on offer don't satisfactorily prepare their

students for any one of the possible careers discussed above. I'm not

saying their hand needs to be held from enrollment right on through to

their first job. That's not the purpose of college. The purpose of

college is to provide a cohesive education, directed to some

relatively well-defined goal of capability and knowledge. Today this

is tragically non-uniform at best, and absent altogether at worst.

So I see plenty of room in software development education for a

clarification of purpose, and a readjustment of goals and curricula. A

few different tracks, each geared toward a distinct section of the

sphere with different goals and different responsibilities. And if we

resolve to use existing terminology with some respect for the

historical meaning of the words, we can re-use our existing

nomenclature. But there can be no more of this muddy slurry of

computer science, craft of programming, and software engineering all

overlapping in claims of purpose, treading on each others' territory

without care. Everyone can have what they are asking for. They just

need to accept that no one can claim the "one true way".