Johann Rost

Robert L. Glass

The Dark Side of Software Engineering

Web Extras by Johann Rost and Robert L. Glass

The views expressed in this blog are solely those of the bloggers and do not represent official positions of the IEEE, the IEEE Computer Society, the IEEE Computer Society Press, or John Wiley & Sons.

Entries with tag computer science.

The Dark Side of Engineering Education?

Poking around in the relevant literature, Johann and I came across a book that looks at Engineering education in a fashion that’s slightly similar to the way we’ve looked at Computer Science and Math.

Robert Glass

The book is Stuff You Don’t Learn in Engineering School -- Skills for Success in the Real World, by Carl Selinger (Wiley/IEEE Press, 2004). What it addresses is engineering’s “soft skills” --  things like working in a team, setting priorities, being effective in meetings, speaking in front of a group, negotiating, dealing with stress, and even having fun (!).

Now, we would agree with the author of the book that these are important skills, particularly for engineers, who are often noted for being too techie and not very “soft.” And we are pleased that he has written a book that covers those topics.

But this is a different kettle of fish from what we are talking about. Our chosen subject is topics that academe should be teaching but is not. Most of us would agree that it is not academe’s role to teach these soft skills, I think. Certainly engineers (and, quite likely, the rest of us) need to learn these things, but I think -- and perhaps you would agree -- that academe is not the place for that to happen. Or at least not in the curriculum of an otherwise highly technical topic.

So there is nothing Dark Side about Selinger’s book. It is worthwhile, and you may want to read it for yourself, but it doesn’t warrant any further discussion on this blog.

A Research Study on What’s Important in the Field of Software Engineering

It’s important, in discussing the Rost/Glass disenchantment with academic coursework regarding its relevance to practice, to mention the work of Timothy Lethbridge [Lethbridge 2000], published over a dozen years ago.

Lethbridge, a Canadian academic, set out to study this very topic as a research project back then. He used a 75-question questionnaire, got it out to 186 practitioner participants (mostly in North America) across 24 countries, and focused on the most important (from the point of view of practitioner desirability) and unimportant courses offered in academe.

This is what he found:

Most important topics:

  • Specific programming languages
  • Data structures
  • Software design and patterns
  • Software architecture
  • Requirements gathering/analysis
  • Object-oriented topics
  • User interfaces
  • Ethics and professionalism

Least important topics

  • VLSI
  • Robotics
  • Differential equations
  • Chemistry
  • Laplace/Fourier transforms
  • Analog electronics
  • Artificial intelligence
  • Combinatorics

Summarizing what is overtaught and undertaught, Lethbridge says:

Overtaught

Calculus, differential equations, linear algebra, chemistry, and physics

Undertaught

The article provides no list of undertaught topics, but draws this important conclusion: “Many of the... important topics are not extensively taught, and some unimportant topics are extensively taught. This suggests that the education that today’s computing professionals receive may not be entirely appropriate.

Most respondents also said that they had forgotten what they learned about many topics (presumably because they had not been reinforced since then by heavy usage). Most of that forgetting had happened in theory and mathematics and the natural sciences.

The article concluded with subjects for which there was a “knowledge gap,” where the importance of a topic to practitioners exceeds their current knowledge. These included negotiation, user interfaces, leadership, real-time system design, management, software cost estimation, and a few others.

The bottom line here is this: Lethbridge’s study tends to support rather strongly the Rost/Glass impression of the relevance of academic coursework, at least in the software field. The gap between what is learned and what should be learned is far too large.

Reference:

Timothy C. Lethbridge, “What Knowledge Is Important to a Software Professional?” Computer, vol. 33, no. 5, May 2000, pp. 44-50. http://doi.ieeecomputersociety.org/10.1109/2.841783

Some New Thoughts from Prof. Lethbridge

by Timothy C. Lethbridge

Regarding my year 2000 study, I haven't personally done any follow-up, although it is on my medium-term agenda.

My article is cited by quite a lot of other papers, so it would be useful to give people an update to cite instead.

My finding that User Interfaces is the area with the greatest knowledge gap seems to have been well received. The topic became required in curriculum SE2004 for software engineering programs and is on track to be required for Computer Science programs in the 2013 update of the CS recommendations. People have told me that my paper is one of the influences that have led to this (directly or indirectly).

If I look back at the courses I took in University and the material I have learned since (out of need, or because I was teaching it), the following would be my words of wisdom:

1. Above all, doing well in SE requires “practice, practice, practice.” Simply doing a lot of development, with sufficient variety so as to keep developing new skills and learning new knowledge, is key. This suggests courses should all require lots of programming coupled with design, with the need for individual work; otherwise some team members can tend to do it all.

2. There are some useful things that I think I would not have learned easily or well if I had not been forced to learn them in a classroom or in some other structured education/training setting. These include statistics (applied, not theoretical), user interface evaluation, algorithm analysis, data structures, design of class diagrams and normalized databases, aspects of linear algebra, logic, numerical methods and grammars, and certain core domain-specific concepts that are widely useful, such as basic accounting, economics, and other business concepts. All these should be in the core of an education program.

3. There is a lot of stuff that can be learned “on the job” and with quick training courses for employees to teach them specifics: much of requirements engineering, much of project management, much of software architecture, and specifics of any particular programming language or platform. A good “general background course” will be enough for most people to get the terminology of some of these topics, and the “practice, practice, practice” concept plus some targeted reading and short seminars will allow them to pick up what they need when they need it.

4. There is a bunch of material that falls between points 3 and 4. Developers may need it in specific contexts, and learning it on the job is less likely to happen, but once people have an awareness of their lack of knowledge, they can use self-study and more in-depth training courses to bring themselves up to speed while in the workforce. This includes real-time design, the full spectrum of testing techniques (for the person who wants/needs to become an expert), and a variety of other topics.

5. The world is moving toward more agility in development, and the tools and methods for this should be integrated harmoniously into educational programs, since they can help a lot of learning happen transparently: rapid release cycles, focus on the customer's problem, test-driven development, continuous integration, etc. -- all foster self-learning.

Timothy C. Lethbridge, PhD, P.Eng., I.S.P., CSDP
Professor of Software Engineering and Computer Science
University of Ottawa, Canada

The Dark Side of Computer Science Pedagogy

This blog post regarding our book The Dark Side of Software Engineering is at the fringe of thatJohann Rost book’s subject matter. Most of the Dark Side matter in the book is on the subject of writing software and the bad things that happen during that process. This blog post, on the other hand, is about the teaching of computer science, as currently practiced in academe. Still, in my view at least, this is a legitimate dark side computing topic, because I think that what we learned in our CS courses -- that is, the inadequacy of what we learned -- could be seen as representing another dark side of our field.

Did we ever use what we learned in school?

Many years ago I graduated in Computer Science from a university in Germany. Looking back at the coursework of that school, I notice that I really only used in my professional career a ridiculously small fraction of the stuff I learned at that time:

I have never again implemented a compiler for an LR(1) language from scratch. Neither have I used the pattern recognition algorithms which were considered “advanced” at that time. I have not had to work on projects that were so close to the hardware that I had to worry about things like carry bit, trigger impulse, and shift registers. I certainly have never had to find out the minimum number of transistors necessary to implement a given Boolean function (in chip design). I remember Turing Machines, fast growing functions, and the fact that the differential equation of the strings of a guitar can be solved by separating the variables, but this material, like that I mention above, has certainly never been used in practice. I could continue, but I think you get the idea.

It's hard to quantify how much I have used out of all the stuff I learned in required CS courses, but it is a tiny fraction. It seems that the most important thing I took from my CS studies was my diploma. When I became aware of that, I felt, let’s say, a “bit disturbed.” A quick review among a few colleagues and friends revealed that their experience has not been much better than mine. Virtually none of the persons I asked used more than, say, a quarter of the stuff learned during his or her computing studies -- and most of them used much less than 10%.

Even more surprising: Although many colleagues are passing through a similar experience, there is no loud cry of “ALARM.” I wonder, what’s going wrong here? Why it is virtually impossible to define a curriculum that can be re-used in practice to a high extent -- say at least 50% or more? And why there is no broad discussion of this problem?

Why does the CS degree have any value at all?

Let’s have a look at this pedagogy/curriculum problem from the point of view of future employers of CS students -- companies that hire computing professionals.

I suppose that these companies know that the persons who graduate from a CS degree program will use only an insignificantly small fraction of the stuff they have learned there. Despite this, having graduated a CS program gives the candidate a competitive advantage over other candidates who have no such degree. I wonder why.

Why do companies prefer candidates who have a degree? What is the advantage of having graduated in CS -- since most of the knowledge learned there won’t be relevant in practice?

A personal anecdote

I don't want to close this section without sharing a personal experience that contributed a good deal to the motivation for writing this article.

When I was an undergraduate CS student in Germany, we had to take and pass a lecture with the innocent title “Logic.” You might think that therein we learned to draw “logical” conclusions. This, however, was far from the truth.

In this lecture we learned that there are some problems that have a solution and for which you can (mathematically) prove that the solution is valid (“solved problems”). For other (unsolved and open) problems, no such proof exists -- at least not yet. However, there is a third class of problems for which you can prove that proof for the solution will never ever exist. The famous problem of “squaring the circle” is an introductory example to this class of problems: there is a mathematical proof that no one will ever come up with a solution.

A great deal of the lecture covered this “interesting” third class of problems. For example, these problems can be ordered according to their difficulty. All of them are unsolvable, of course, but some of them are more difficult -- more “unsolvable” -- than others. If this concept sounds strange to you at the first glance: Don't worry, you can get used to it in time.

These proofs that a problem will never have a proof are anything but easy. How will you prove such a thing? Perhaps in 300 years a genius will come along with a completely new idea, finds a solution, and can prove it. Despite the difficulty of these proofs in the third class, they are possible, and we learned quite a few of them.

As the lecture advanced, the professor did not give us any more specific proofs for certain problems, but broadened the view and showed us methods for constructing “proofs of non-existing proofs” in general -- we went to the next level of abstraction.

The feeling when I passed the exam was beyond words -- like crossing the Antarctic. If you survive this, you won't catch a cold in windy Chicago any more. Unfortunately, not all of us survived. Of the three hundred students who tried the exam, fifteen of us passed. Those who failed this obligatory exam could repeat the test a couple of times. However, quite a few of my colleagues finally had to give up and leave the university because they simply could not get their brains around this stuff.

The anecdote is based on the specific situation in my school at the time when I was a student, so it certainly cannot be generalized. Some teachers with good reputations in their research fields had very few restrictions regarding the curriculum -- so they taught us whatever they considered really essential in life.

It was a bizarre lecture. However, let's step back and look at the problem from some distance: Given the fact that the students don't use in real life almost anything they learned at university, does it really matter if the students spend their time for one single extraordinarily difficult lecture or for ten lectures with moderate difficulty? Either way, at the end they will have spent a couple of years and will take nothing with them but their graduation document, so this bizarre lecture only highlights the general and widespread problem by driving it to the extreme.

What's your experience?

This blog post is largely based on my personal experience and opinions. I did not conduct a study of this topic, nor do I have special knowledge of curriculum design.

However, the fact that I and many of my colleagues cannot use anything of what we learned at university disturbs me. So, I invite the reader to share his or her own experiences and opinions on this topic.

The Dark Side of Mathematics Pedagogy

Robert Glass

Let’s stretch this whole matter of the dark side’s relationship to pedagogy even further than my co-author of the Dark Side book, Johann Rost, has done above.

Until Johann wrote his article, I had no idea how he felt about his computer science education. But what makes this addendum of mine at least mildly interesting is that I, independently, felt the same way about my education. Except that mine was in Mathematics!

Here’s my experience.

My undergraduate college was a very small one, with very few choices. I majored in Math there, and felt somewhat good about that (although I was never quite sure what profession one could go into with a Math degree). I was a big fish in that small pond, graduating Summa Cum Laude and wondering if I was sufficiently prepared and/or bright enough for the graduate school I had chosen to attend.

I went on to graduate school in Mathematics, choosing the University of Wisconsin as the place to do so because it had an excellent reputation in the Math field. But there was something important that I didn’t know at the time. Academically, Math divides itself into two fields -- Pure Math, for people who love Math for Math’s sake, and Applied Math, for people who want to use Math to solve problems in other fields. I quickly discovered that Pure Math wasn’t the field I wanted to go into.

Time passed, and so did I, but without the distinction I was used to in my smaller college. I decided I wasn’t cut out for the PhD I originally thought I was studying for and found a job in industry, in the suddenly burgeoning computing field into which I found I fit comfortably immediately. There is an old joke that all programmers believe they’re the world’s best (I strongly believe that’s why Open Source programmers trumpet that viewpoint about their own work so frequently), and I can certainly relate to that, since I immediately thought I was a considerably-above-average programmer! (That reminds me of another joke, in which the residents of the fictional town of Lake Woebegone, Wisconsin, believe all of their children are above average!)

In any case, when I joined industry (where I became part of the also-burgeoning space industry), I quickly found that my education (in Pure Math, you recall) had not in the slightest prepared me for the work I was going to be doing. Actually, that’s not quite true. I had taken the only two courses Wisconsin had in working with computers (this was 1952, and the whole computing thing and the whole space thing were both brand new), and those were superb preparation for the work I was to do. But none of my Math applied. At all. 0%.

Which is kind of weird. Because my job assignment was in Master Dimensions, where we mathematicians (!) used our skill to define the aircraft our company was building in mathematical terms. We measured things to a ten-thousandth of an inch, so that when the airplanes flew the pieces would fit together so well that no excess air turbulence would cause bad things to happen. We Master Dimensions folks felt exceedingly useful (although knowing what tolerances we were working to, we were always dismayed when we observed shop floor workers banging on pieces to make them fit together -- we knew, in our hearts, that they would slip together astonishingly well without banging!

Now the kind of Math we were working with here was 3-dimensional geometry. And if you know Math curricula at all, you’re no doubt aware that that’s a subject that almost no one teaches. And certainly not a school that focuses on pure math.

The more I thought about it, the more I realized that my Math studies had prepared me for almost nothing I was doing on the job, even though I was, nominally, a Mathematician! I began to realize that what my college education had been good for was a ticket of achievement, called a degree, that showed I was bright enough to learn new things, perhaps even Master Dimensions work! It turns out that I wasn’t all that good at Master Dimensions work, either, and I quickly changed fields to go full time into software work, where of course I immediately became the world’s best programmer (like all of my colleagues).

So there you are. Putting Johann’s two cents’ worth with mine, one could begin to wonder about the value of a college education. I’m not saying, and I don’t think Johann is saying, that the education -- or the degree -- wasn’t worthwhile. It’s just that I have the suspicion that it could have been so much more valuable if the academics who taught my courses had (a) known I was going to be an applied mathematician, and (b) had any idea what real-world problems actually looked like.

All of this makes me wonder if the feeling that your education didn’t properly prepare you for your professional work is universal. Perhaps it’s not CS education, or math education, that’s the problem here. Perhaps it’s academe in general. Perhaps there’s just a huge gap between the academic view and the professional view in all (or nearly all) disciplines? That makes it all the more important that you communicate with us. Did your education, no matter what its flavor/major, serve you well in being job-ready? We’d love to hear from you.

Showing 2 results.

About the Book

Cover image

The Dark Side of Software Engineering

Evil on Computing Projects

 

by Johann Rost and Robert L. Glass

Betrayal! Corruption! Software engineering?

Industry experts Johann Rost and Robert L. Glass explore the seamy underbelly of software engineering in this timely report on and analysis of the prevalence of subversion, lying, hacking, and espionage on every level of software project management. Based on the authors' original research and augmented by frank discussion and insights from other well-respected figures, The Dark Side of Software Engineering goes where other management studies fear to tread -- a corporate environment where schedules are fabricated, trust is betrayed, millions of dollars are lost, and there is a serious need for the kind of corrective action that this book ultimately proposes.

IEEE CS MEMBERS: Use promotion code 38491 when you check out at Wiley.com to receive your 15% member discount.

ISBN: 978-0-470-59717-0
Paperback
305 pages
$34.95 (15% member discount available)