Tuesday, January 29, 2008

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".

9 comments:

Steve said...

I don't know that I see the solution as three disparate degrees, but as a sort of specialization of the Associates in Programming. Take medicine for example; you could be a general physician or a specialized neurologist. Similarly, you can choose the aspects of software development as a craft that you wish to focus on.

An Associates in Programming degree would teach you the basics (thinking with pointers, recursion, OOD concepts) you'd need to be a successful programmer. Things you'd probably find useful for either CS or SE (as you describe them).

Then after your two years, you would switch to your focus. Either CS where you'd get your lambda calculus, compiler building, and your highly theoretical concepts. Or you could choose SE, where you would learn how to engineer your projects to produce highly predictable estimates, how to manage resources, and the other specialized pragmatic development concepts.

Steve said...

I forgot to mention that you could also only get your associates, and not proceed to the CompSci or SE specializations.

Also, I still see the CS and SE being four year degrees.

Chris Ammerman said...

I should have said it clearly, but yes I intended that the Associate degree could lead into either of the two Bachelor degrees in a 2+2 manner.

I really like your comparison to medical education.

It's something I hadn't thought of before, and I don't know if we're there quite yet, as an industry. But as the industry continues to grow both broader and deeper, and different disciplines continue to diverge further from one another, I can definitely see the practice of software development evolving a similar model as what we see in the medical or legal fields.

Nate said...

Good ideas, and I agree that CS degrees need to be more job applicable. Personally, I'm not sure if I need a whole rework of my degree (probably because I feel like my degree was very close to the "Bachelor of Science in Computer Science" that you describe, less the "real world dev environments") but just a couple classes cluing me into what is most graduates encounter when they start their jobs would have helped.

@Steve: I too like your medical reference, but I don't really think that it is practical...unless you are talking about graduate work. But even then, what makes a neurologist ready to be
"real world ready" when they finish their education is the interning and residencies they do with trained professionals to reinforce their class work.

Steve said...

@Nate: Excellent point about the internships/residencies. I think that's something that should be strongly encouraged, or even facilitated by the university you're attending.

Also, I didn't mean to touch on the stringent requirements that makes a doctor a doctor. I was mainly alluding to the benefits of choosing your specialty, as in medicine. The student benefits because you choose a discipline as a junior; when you know more about your field that you enjoy or are interested in. The employers benefit because when they need to hire, they can bring in people of a particular specialty and know they have a strong skill set/passion for that specialty.

It would then be up to the university to prepare the student as best they can for the real world needs of their field.

chuck said...

I really like where you're going with this. I had a kinda similar idea but didn't think through nearly so well.

To some extent, we already have this -- I started out my attempt to get into the software business by getting a two-year Associate of Applied Science from a small business college. Unfortunately their program didn't have anything about source control or any of what I think were the really important bits you describe in the Associate degree section. Also, what I found was that after getting this degree, I still couldn't seem to get any programming jobs-- everything I could find advertised said a Bachelors degree was required. It's fine to propose a two-year degree in computer programming as a good course for people looking to get jobs as programmers, but it won't be worthwhile if we can't convince employers to hire holders of such a degree as programmers.

I ended up pursuing a BS in CS at university, partly because it seemed to be necessary to get any of the jobs I was interested in, and partly because I thought that stuff was interesting anyway and really didn't /feel/ like I knew enough theory for my linking.

Chris Ammerman said...

@chuck:

I meant to address this as part of my section on the Associate degree, but there were a million thoughts I had in writing this up, and this one just plain got lost.

Ravi Mohan and Reg Braithwaite (a.k.a. Raganwald) both express their distaste with this cultural phenomenon, but seem to accept the inevitability of it as well.

I think that may be true to a certain extent among large companies/corporations. But I haven't given up on the whole market yet.

Offshore resources unfortunately inhabit a similar position in the market as these Associate degree holders would, price-wise. Unfortunately I think big companies, who can afford the non-personnel overhead cost of outsourcing, are going to side with the cheap, offshore, 4-year grad. I would think smaller companies would be more likely to give these 2-year guys a shot, though. In total dollars, they're going to be much cheaper.

Jim Law said...

Have you checked out Richard Gabriel's essays on this at http://dreamsongs.com/Projects.html ?

The Feyerabend Project and his Master of Fine Arts in Software are both interesting.

Chris Ammerman said...

@jim:

I hadn't seen those before, so thanks for the link. That MFA proposal is very interesting.