Sign In

Communications of the ACM


What Should We Teach New Software Developers? Why?

whiteboard eraser

Fundamental changes to computer science education are required to better address the needs of industry.

The full text of this article is premium content


Charles Betz

Excellent article.

Re: "The idea of software development as an assembly line manned by semi-skilled interchangeable workers is fundamentally flawed and wasteful." This has been a common theme in much SDLC-related commentary. Some argue that *no* metaphor is applicable. I have more recently begun to ask whether product development is actually the appropriate metaphor. Product development and portfolio management in industry is costly, iterative, and risky process, subject to many of the same issues as software. Yet I have seen little if any exploration of potential parallels.

Charles T. Betz
Enterprise Architect
Wells Fargo Bank, N.A.

Ingo Lutkebohle

As an academic once tasked with overhauling the software engineering undergrad course, I can wholeheartedly underwrite this article. One sentence, in particular, stood out for me: "Proprietary tools for dealing with huge code bases written in archaic styles don't fit this model."

I believe that /the/ core issue is that academic computer science has a hard time working in a meaningful way on "huge code bases". Yet, as Mr. Stroustrup often mentions and I wholeheartdely agree with, scale is precisely the distinctive difference.

However, it seems that it is not entirely clear how to achieve this. My suggestion would be that we should create a meaningful incentive system for academic research. That is, some way that allows research to do its job and measure its applicability to the real world issues. I bet many academics would love to do this, instead of work on purely theoretical issues.

My suggestion how to gou about this would be to create accepted tools for dealing with large-scale code bases. Tools to measure, quantify, summarize, correlate, generalize, and more abstract analysis on top of those. Some tools in this direction are already available. We also need tools to /modify/, or maybe "refactor" such code-bases and make comparisons, so that the effect of different engineering approaches can be verified. Also, some early tools in this direction exist.

Such tools would enable researchers to work on large-scale issues, as is needed.

Last, not least and probably not easiest, collaboration with experts on the "soft" issues could enable psychologically-grounded metrics for, just as one example, API usability and complexity, so that again, the effect of different choices can be measured.

Robert Szymczak

>>For many, "programming" has become a strange combination of unprincipled hacking and invoking other people's libraries (with only the vaguest idea of what's going on).<<

This is an excellent observation, and unfortunately, very true...

Lawrence Bernstein

Bjarne makes an insightful and provocative plea for a more professional software industry. People that will write programs need to be taught by people who are skilled in detailed design, data structure, code design and all the other computer science skills. There is no excuse for Computer Science Professors not writing some code or at least being able to critically read code. The computer science education by Bjarne teaches the student to write professional programs. Fred Brooks teaches that we need another order of magnitude effort to take the program and produce a programming system product from it. This additional effort is learned in software engineering programs.

Must a software engineer be a professional programmer? i think not, but they must be taught the essentials of program design. I think that software engineers must be able to solve system problems for software intensive systems. Alternatively, these people could be called systems engineers well educated in software technologies and processes.

We need people educated in software who can solve real problems. No single standard educational course of study focuses soley on this need.

Kiran Achyutuni

Excellent and thought provoking article. Here is a suggestion for improving the quality of CS graduates: What if the entire University were to run on the software produced by the University CS students?

Granted, this is not possible on day one, but if the University were to adopt this policy, over time, CS students would have hands on experience with real-life code bases and will learn all parts of software design and development. They will learn how to fix bugs, test, refactor code, appreciate the importance of good software coding practices. They will also learn how to add new features by interacting with customers. Professors can take actual code snippets and teach students with it. Best of all, students can see the results of their efforts before they graduate.

I bet if the University is bold enough to adopt this policy, I can guarantee that the students of this university will be highly valued by industry. This is a win-win for all: Students, Professors, University, and the Industry.

Some of the great companies have such an internal policy - all systems sold by the company must be used internally for the same purpose. Companies like Oracle, Microsoft, do this everyday. The University can do the same and should do this if it is serious about the quality of the CS graduates it produces.

Kiran Achyutuni,

The account that made this comment no longer exists.

Interesting discussion. CS is about complexity theory, computability, algorithms, data structures, automata theory, quantum computation science, formal languages and much more. There's a whole theoretical background that is unique to CS.

Definitely, there should be separated majors, such as Software Engineering or Data and Information Management, in order to avoid misconceptions and to address industry's specific needs.

In short, CS is a basic science in wich we can learn about modelling the complex processes that occur in Nature by using abstract mathematical tools. The models we construct in CS (basically, algorithms) have to (i) be given formal descriptions and proofs; (ii) have its fundamental properties investigated (complexity bounds, completeness, etc.); and much more.

In short, CS is a basic science and other sciences can benefit from it as well by using its outocomes. An example of this is Artificial Intelligence. Although it first got inspiration from early mathematical models of the brain (neuroscience), it became clear thereafter that the 'algorithimic' way of modelling natural processess would be fundamental to AI. Today, AI is commonly regarded as a standard discipline in CS, though still multidisciplinary.

So, why not segregate the lots of teaching contents flooding CS students minds into separate majors?

Furthermore, let's not forget the revealing quote of a prominient computer scientist:

"Computer Science is no more about computers than Astronomy is about telescopes" Edsger Dijkstra

That summarizes well what CS is definitely not about.

I believe that multidisciplinarity should be raise from a well planned reform in the graduate educational system, instead of requiring that a CS major covers every single topic from software engenieering to computation theory. Both are, separetedly, deep and complex enough disciplines to be studied in their own terms.

Carlos R. B. Azevedo
MSc Candidate in CS
Center for Informatics (CIn)
Federal University of Pernambuco
Recife, Brazil


This article is a true an eye-opener for both the academia and the industry.
I am glad to see that a professional researcher from an reputed IT company is now teaching (the author of this article) at a university. It is
an noble gesture and gives a hope that a saviour of the IT industry has emerged among us.

This is another amazing article that should shake the mindset of
both academia and industry. I do agree with the most of the views expressed by the author.
Even today, I am scared while flying in these planes controlled by a computer
that are programmed by a group of undisciplined, unlicenced, and unaccountable IT Professionals.
It is a miracle that unitl now many of these life-critical systems are running without crashing.
I do agree with the author that a "software nuclear bomb" might be lurking
deep down in some untested part of the software in these critical
systems. When a part of the software code that was untested gets executed becasue of an unforeseen real-life scenarios,
it will break havoc in human lives.

One of the Indian Medical Practioner (Dr. Devi Shetty, Narayana Hrudayala) predicted that remotely controlled
robotic surgery is possible in the future. It give me a chill through my spine to imagine that an unsuspecting patient
had to surrender his/her 'Made-by-the-God' body to a doctor sitting on the other side of the globe controlling a robot-controlled knife
cutting a delicate structure of the patient's body. Even a small bug in the software code will prove disastrous for
the helpless patient on the surgery table!

We the intellectuals should predict the future problems and take the necessary precautions before it is loo late.
As being just wise people (who learn from other mistakes) or fools (who learn from their own mistakes) is not sufficient at all!

To brigde the academia and industry, I agree with the author that professors who teach should build large systems once in 5 or 10 years
for a duration of 2 to 3 years in the industry to appreciate the reality.
In the same way, the seasoned IT professionals should go back to academia to teach (and learn in the process) and imbibe the rigour of the programming, new tools and ideas.
I think, this cross-fertilization between academia and industry will help the both sides in the long-run.

I agree with Kiran Achyutuni's comment that the products from the IT industry should have "eat your own dog food" policy by using the products themselves internally before it is sold to the external users.
The "eat your own dog food" policy will reinstate the much needed trust into the products sold by the IT companies. It is pity that these companies protect themselves by making the use to agree to the terms in the licencing agreement that clerverly gain the impunity.

Saya Sreenivasulu
Reading, UK.


i agree with the point of cross-fertilization between academia and industry by Saya Sreenivasulu, but who will ensure the result. because in IT industry one may move slow, one may move fast , depends on their own passion , but nobody can say whose technology changes in which rate and how they learn and how they teach to next. so i can not appreciate if an academic goes to industry and make waste of others time and same to professionals. it may possible if it happens side by side.

Partha Sarathi Paul


I think the core of the issue is academia itself. The institution has grown so large and so proud and so necessary because it spits out professionals that can't judge skill because they're brainwashed to believe that academia can prepare a person for professionalism.

Mentored practice prepares a person for professionalism, and the common usage of the term pro doesn't match the field. A professional is competent in their field, but so far, all I've seen is a lack of competence.

Academia takes us as far as it can with generic studies, and idealistic classes. As far as it can ruin minds and under appreciate mold-breakers.

The problem is the vicious cycle of judging the abilities of a person based on their degree. Most of which industry doesn't appreciate, because as soon as you're hired they melt you down to forge their golden sheep idol of nose down, and practical lackadaisical application of proverbial duct-tape need only apply.

The stench of the Microwave Society running timer set to fix-it-and-fix-it-now, fills the air.

If only other fields worked the same way. Let's build a bridge and just start working. Don't bother measuring, if we miss the road, we'll just alter the road to match, even if we lose a few ramps access to the highway. Hmm it's cracked.... pour in cement call it a day.

I feel the Jenga tower starting to shift, shall we take out more of our solid dynamic well-defined meta-code and replace it with hard coded magic numbers and flags? Just add one more flag. Make it work. Put a stamp on it so someone knows you're doing something at work.

I appreciate your attempts to mold the academia to fit the industries needs, and to mold industry to utilize technology appropriately so that academia prepares adequately, but it's academia from whence forth industry came, and it's academia against which it holds its work-force measuring rod.


The problem is the vicious cycle of judging the abilities of a person based on their degree. Most of which industry doesn't appreciate, because as soon as you're hired they melt you down to forge their golden sheep idol of nose down, and practical lackadaisical application of proverbial duct-tape need only apply.

View More Comments

Log in to Read the Full Article

Sign In

Sign in using your ACM Web Account username and password to access premium content if you are an ACM member, Communications subscriber or Digital Library subscriber.

Need Access?

Please select one of the options below for access to premium content and features.

Create a Web Account

If you are already an ACM member, Communications subscriber, or Digital Library subscriber, please set up a web account to access premium content on this site.

Join the ACM

Become a member to take full advantage of ACM's outstanding computing information resources, networking opportunities, and other benefits.

Subscribe to Communications of the ACM Magazine

Get full access to 50+ years of CACM content and receive the print version of the magazine monthly.

Purchase the Article

Non-members can purchase this article or a copy of the magazine in which it appears.
Sign In for Full Access
» Forgot Password? » Create an ACM Web Account