As I've mentioned a few times in recent months that I am teaching our intro course this semester for the first time in a decade or so. After only two weeks, I have realized this: Teaching CS1 every so often is a very good idea for a computer science professor!
With students who have no programming background, I cannot take anything for granted: values, types, variables, ... expressions, statements, functions/methods ... reference, binding ... so many fundamental concepts to build! In one sense, we have to build them from scratch, because students have no programming knowledge to which we can connect. But they do have a lot of knowledge of the world, and they know something about computers and files as users, and we can sometimes get leverage from this understanding. So far, I remain of the view that we can build the concepts in many different orders. The context in which students learn guides the ordering of concepts, by making some concepts relatively more or less "fundamental". The media computation approach of Guzdial and Ericson has been a refreshing change for me -- the idea of a method "happened" naturally quite early, as a group of operations that we have applied repeatedly from Dr. Java's interactions pane. Growing ideas and programs this way lets students learn bottom-up but see useful ideas as soon as they become useful.
I've spent a lot of time so far talking about the many different kind of names that we use and define when thinking computationally. So much of what we do in computing is combining parts, abstracting from them an idea, and then giving the idea a name. We name values (constant), arbitrary or changing values (variable), kinds of values (type, class), processes (function, method)... Then we have arguments and parameters, which are special kinds of arbitrary values, and even files -- whose names are, in an important way, outside of our programs. I hope that my students are appreciating this Big Idea already.
And then there is all of the jargon that we computer folks use. I have to assume that my students don't know what any of that jargon means, which means that (1) I can't use much, for fear of making the class sound like a sea of Babel, and (2) I have to define what I use. Today, for example, I found myself wanting to say "hard-coded", as such as a constant hard-coded into a method. I caught myself and tried to relate it to what we were doing, so that students would know what I meant, both now and later.
I often speak with friends and colleagues who teach a lot of CS as trainers in industry. I wonder if they ever get a chance to teach a CS1 course or something like it. The experience is quite different for me from teaching even a new programming style to sophomores and juniors. There, I can take so much for granted, and focus on differences. But for my intro student the difference isn't between two somethings, but something and nothing.
However, I also think that we have overglamorized how difficult it is to learn to program. I am not saying that learning to program is easy; it is tough, with ideas and abstractions that go beyond what many students encounter. But I think that sometimes lure ourselves into something of a Zeno's paradox: "This concept is so difficult to learn; let's break it down into parts..." Well, then that part is so difficult to learn that we break it down into parts. Do this recursively, ad infinitum, and soon we have made things more difficult than they really are -- and worse, we've made them incredibly boring and devoid of context. If we just work from a simple context, such as media computation, we can use the environment to guide us a bit, and when we reach a short leap, we make it, and trust our students to follow. Answer questions and provide support, but don't shy away from the idea.
That's what I'm thinking this afternoon at least. Then again, it's only the end of our second week of classes!
At last report, I had had a good 22-miler, which was my first comfortable long run of the year. My 18- and 20-milers had been struggles, due in part to weather and in part to the fact that I was still regaining strength and stamina from reduced mileage in the spring. But I was wary of feeling too good, because I still faced my longest test of the year.
This year I am again training on a three-week cycle, something like an iteration in agile development. For two weeks, I increase mileage, including the Sunday long run, and then in the third I cut back a bit, to consolidate my gains and to prepare for the next increase. My tough 18- and 20-milers had been part of a 50-52-48 iteration, capped off with a 12-miler. The 22-miler was the end of the first week in a 54-56-52 iteration.
Well, I did my longest run of the year at the end of Week 2, four times around a 10K loop in the local park. That comes to 24.8 miles, though I record it as a 24-miler. It went very well. I felt strong throughout, ran negative splits for all four laps, and finished in 3:34:25 -- about 9 minutes under my upper bound of 9:00/mile. The last mile of my first three laps took 9:16, 9:04, and 8:46, and then I closed the last lap with consecutive miles of 8:32, 8:46, 7:58, and 7:34. This wasn't nearly as fast as last year's 40K, but it was perfect as a training run -- fast, but not too fast. If I run the long runs too fast, then I won't be able to gain as much from my upcoming speed workouts; plus I run an increased risk of injury or simply burning out. Patience, patience!
With a marathon goal pace of 8:00/mile, I felt good knowing that I could close with two sub-8:00-minute miles at the end of a 110-mile fortnight. On race day, I will have run only 20 miles or so in the preceding week, all in short distances and none too fast. The body will, I hope be recovered and ready for a long, hard push.
Even better, I ran that well with only two bathroom breaks, taking no energy gels, and drinking only about 16 ounces of sports drink. And I still felt good later that day! As I have begun telling folks, I wonder if my body isn't better suited for even longer distances, the so-called "ultra" races. (No, I'm not ready to put my mileage where my mouth is just yet.)
My consolidation week went very well. I ran only 49 miles after giving myself a day off after the 40K. My speed workouts pushed me long -- 5x1600m and 10 miles at marathon goal pace -- and then I ran a long run of 16 miles in under an 8:30/mile pace. I haven't run that route so fast in at least a year. Again, I felt strong.
I'm now beginning the final iteration of my training, a two-week cycle of 58-60 that ends as my three-week taper begins. I don't need a consolidation/recovery week, because the taper gives me three weeks of the same. My long runs will be only 22 and 20 miles, which means that I am bulking up my midweek runs. I'm going to stick with a 10-mile max on my Wednesday and Friday speed workouts, so Tuesday and Thursday will be the days that see more miles. I am curious to see what my long runs feel like these weeks, especially if I try to speed them up to an 8:30/mile pace throughout.
What I really need to do is find a way to sleep more hours, but there are only so many in a day. With the start of the school year, both for me and my daughters, I don't have much leeway. That is one of the big challenges for me, and one of the reasons I've never tried an April or May marathon, when all of my training would occur during a semester. My training partner for this race, though, lives in Arkansas, and he is suffering through the heat and humidity of the south just to get ready to run with me in October. I definitely owe him one and so will likely find out what training for a spring marathon is really like -- and soon!
Next up, in the morning: a 10-mile speed workout, 800m repeats, I think. Time to go fuel up.
This week I've had the opportunity to meet with several colleagues from around my college, as part of some committee work I had volunteered for. This sort of extra work is often just that -- extra work -- but sometimes it is an opportunity to be reminded that I have some impressive colleagues. Sometimes, I even learn something new or am prompted to think about an idea that hadn't occurred to me before.
One of my colleagues spoke of how important it is to get the science faculty working more closely with one another at this time. He couched his ideas in historical terms. Science in the early 20th century was quite interdisciplinary, but as the disciplines matured within the dominant paradigms they became more and more specialized. The second half of the century was marked by great specialization, even with the various disciplines themselves. Computer science grew out of mathematics, largely, as a specialty, and over the course of the century it became quite specialized itself. Even within artificial intelligence, the area in which I did my research, became almost balkanized as a set of communities that didn't communicate much. But the sciences seem to have come back to an era of interdisciplinary work, and CS is participating in that, too. Bioinformatics, computational chemistry, physics students rediscovering computer programming for their own research -- all are indications that we have entered the new era, and CS is a fundamental player in helping scientists redefine what they do and how they do it.
Another colleague spoke eloquently of why we need to work hard to convince young people to enter the sciences at the university level. He said something to the effect that "Society does not need a lot of scientists, but the ones it does need, it needs very much -- and it needs them to be very good!" That really stuck with me. In an era when university funding may become tied to business performance, we have to be ready to argue the importance of departments with small numbers of majors, even if they aren't compensating with massive gen-ed credit hours.
Finally, a third colleague spoke of the "rhythm" of an administrator's professional life. Administrators often seek out their new positions because they have a set of skills well-suited to lead, or even a vision of where they want to help their colleagues go. But minutiae often dominate the daily life of the administrator. Opportunities to lead, to exercise vision, to think "big" come along as fleeting moments in the day. What a joy they are -- but you have to be alert, watching for them to arise, and then act with some intensity to make them fruitful.
For some reason, this reminded me of how sports and other competitive activities work. In particular, I recall a comment Justin Henin-Hardenne made at Wimbledon this year, after her semifinal win, I think. She spoke of how tennis is long string of mostly ordinary points, with an occasional moment of opportunity to change the direction of the match. She had won that day, she thought, because she had recognized and played those big points better than her opponent. I remember that feeling from playing tennis as a youth, usually on the losing end!, and from playing chess, where my results were sometimes better. And now, after a year as an administrator, I know what my colleague meant. But I'm not sure I had quite thought of it in these terms before.
Sometimes, you can learn something interesting when doing routine committee work. I guess I just have to be alert, watching for them to arise, and then act with some intensity to make them fruitful.
(And of course I'm not only an administrator... I'm having fun with my first week of CS1 and will write more as the week winds down and I have a chance to digest what I'm thinking.)
Students are back on campus, and classes are back in session. Though the department office moved into its new building in March, and the rest of the faculty moved in in May, this was our first chance to use our classrooms and meeting spaces "in anger". So, in addition to the usual first-day questions that walk into the department office, we got to track down ethernet ports and cables, transparency pens, and all the details of living in our space. The result was a busy day, and a good one in the end. Some of the usual questions were unusual, too -- for instance, I was asked to find a student a substitution course for Keyboarding 101, which s/he had failed at a previous university. Sadly for the student but good for us, we do not offer courses in keyboarding!
The emcee at our university convocation used the title phrase above when speaking with some faculty yesterday. (He is a theater prof, with a flourish for the dramatic.) It captures how most faculty, staff, and students feel this time of year. This is our New Year. It is the time for fresh opportunities, new year's resolutions, and clean desks. Most folks are rested and ready to dig back into the teaching business of the university. Every course is still perfect, the ideal held in our minds all summer. Students are still eager to find their classrooms and figure out what their courses and professors will be like.
In a couple of weeks, the ideal will be shattered: homework will hang over our heads to be done and graded... we'll have botched a lecture or three... the desk will be a mess... and some folks will already be looking ahead to our Baby New Year in January. But not today.
My class starts tomorrow, and I too am flush with the expectation of a new year. I teach CS I this fall for the first time in a decade, and I'm using a new approach for our department. I'm excited by the prospect of 24 students in class tomorrow. I may adapt some ideas from my talk on steganography last spring as my opening to the course, which could be fun -- but it's also a bit of a risk, the sort of risk that can quickly lead to "wait 'til next year...". I've also followed up on a promise to equip my course web site with a newsfeed, by using the same blog engine I use to publish this blog. One of our new adjuncts is blogging his senior-level Networking web site, too, which gives us an interesting experiment this semester into how many of our students are using newsreaders at this point in time, if any.
Now, off to get ready to actually teach the course...
If you've read many of my entries on agile software development, you know that I run the risk of being one of those guys who see agile principles everywhere I look in the world. I've certainly explored the relationship between agile approaches and my running. I've even seen agile truths a Bill Murray film.
One way to do an analogy, and the people who use it, a disservice is take it too far, to go beyond where it adds value to where it misleads. But sometimes when we see something everywhere it's because it is everywhere, in some form. What's the pattern?
I was again struck by the similarities between agile software development and teaching techniques while reading an article recently. Another department head in my college shared some of the papers she has been reading on how to improve the way we teach large, general-education courses. One of these papers is a product of the National Center for Academic Transformation, a project based on two ideas:
The project currently focuses on the largest of courses in order to maximize its effect. According to Twigg, "just 25 courses generate about half of all student enrollments in community colleges and about a third of all enrollments in four-year institutions". This had never occurred to me but isn't too surprising, given that nearly all colleges students at every school take a common set of introductory courses in English, mathematics, science, and business. What did surprise me was the typical failure rates in these courses: 15% at research universities, 30-40% at comprehensive universities, and 50-60% at community colleges. Some of these failures are certainly the result of filtering out students who shouldn't be in college, but I have to think that a significant percentage of the failures are by people who have been poorly served by a lecture-only section of 100s of people.
What does agile software development have to do with all this? In order to improve the quality of instruction (including the failure rates in these large and common courses) and reduce the cost of teaching them (in a climate of declining funding and rising expenses), this paper recommends that universities change the way they design and teach university courses -- in ways that echo how agile developers work, and using information technology to automate whatever automation can improve.
One of the fundamental principles of this transformation is continuous assessment and feedback. Rather than testing students only with a midterm and a final, an instructor should keep in continuous touch with how students are comprehending the material. The traditional way to do this is to administer frequent quizzes, but that approach has as many minuses as plusses. Grading all those quizzes is a pain no sane instructor relishes, and you end up using a lot of class time taking quizzes.
Technology can help here, if we think about automating continuous assessment and feedback. On-line quizzes can give students an opportunity to test their understanding frequently and receive feedback about what they know and don't know, and they can provide the instructor with feedback about both individuals and the group. Other technology can be more continuous yet, allowing instructors to quiz students "on the fly" and receive aggregated results immediately, a la Who Wants to be a Millionaire? Folks at my university have begun to use interactive feedback tools of this sort, but they haven't made their way into my department yet. Our most common immediate assessment-and-feedback tool is still the compiler.
But the agile programmers -- and agile-thinking instructors -- among us know all about automating continuous assessment and feedback, and use more tools: IDEs that provide immediate compilation of code ... unit testing frameworks. Red bar, green bar! These tools help students know right where they are all the time, getting past some of the ticky-tack syntax issue that unnecessarily interfere with new students' progress. I think it's a huge win to let the IDE point out "you forgot a semicolon..." and "your code doesn't pass this test...".
There is a risk in allowing students to develop a "do it 'til you get it right" mindset, but CS folks have already had to deal with this with the easy availability of compilers. Two years ago -- almost exactly! -- I wrote about this issue of multiple iterations and care for programs. Many professors still don't like that students can and do go through many compile iterations. Since that time, I've become even further convinced that students should do this, but learn how to do it right. People master skills by careful repetition, so we need to let them use repetition -- carefully, thoughtfully. In some ays, this seems like a statistical problem. To succeed by making random tries but never learning, they need to have time for a lot of tries. If they have that much time, then they have too little to do!
The rest of the paper outlines other agile-sounding techniques: increased student interaction (pair programming), continuous support (the coach, and access to the working system), and sharing resources (collective ownership). But the key is feedback, and the use of automation to do this as cleanly and painlessly as possible.
Ultimately, I just like the mentality these folks have about teaching. Twigg quotes a math prof involved with the project as saying, "Students learn math by doing math, not by listening to somebody talking about doing math." Of course! But you'd never know it by looking at most university courses.
This sort of re-design requires a big change in how instructors behave, too, and that change is harder to effect than the one in students. Instructors are no longer primarily responsible for introducing basic material. (Isn't that what reading is for?) Instead, they need to be able to review what students have done and expand on it in real-time, extending what students do and leading them to new ideas and to integration of ideas. That's intimidating to most of us and so requires a whole new brain.
Just a quick update on preparation for the Twin Cities. What a difference two weeks can make.
My 20-miler two weeks ago didn't feel all that good to me. It was hot and humid, and I was sore and tired. At the end, I was wiped out for a day or two.
This morning was cool and dry. My legs felt a little heavy, but I was able to run 9-minute miles without much effort, I was starting to drag by the 14-mile mark, so I did two things: drank a little Powerade and set my mind on picking the pace up to 8:30/mile for a marked four-mile stretch up ahead. You might think that thinking about speeding up would be the wrong thing for me to do when I start dragging, but in this case I judged the fatigue to be more mental than physical. My legs weren't slowing down; I was just feeling the weight of the miles left to run. In such a case, I find that I can perk myself up with a little speed-up. It gives my mind something positive to focus on and improves my mood.
I've been successful doing this on training rains the last few years, but during my marathons. I wonder what I can do in six weeks to convert this into a racing tool?
The fast four miles went better than expected: 8:10, 8:12, 7:52, 7:47. That's a cool 32:01 -- my marathon goal pace. And the last two miles coming home felt just fine.
A much better day. Let's see what next week's 24-miler, the crest of my mileage buildup, brings.
The next book on my nightstand is Talking About Leaving: Why Undergraduates Leave the Sciences, by Elaine Seymour and Nancy Hewitt. The dean and department heads in my college have had an ongoing discussion of national trends in university enrollment in mathematics and the sciences, because all of our departments with the exception of biology have seen their number of majors drop in recent years. If we can understand the issue better, perhaps we can address it. Are students losing interest in the sciences in college? In high school? In grade school? Why? One of the common themes on this blog for the last year or so has been apparent declining interest in CS among students both at the university and in the K-12 system. At this point, all I know is that this is a complex problem with a lot of different components. Figuring out which components play the largest role, and which ones we as university faculty and as citizens can affect, is the challenge.
My net acquaintance Chad Orzel, a physicist, recently commented on why they're leaving, drawing his inspiration from an Inside Higher Ed piece of the same name. That article offers four explanations for why students leave the physical sciences and engineering disciplines: lower GPAs, weed-out courses, large and impersonal sections, and "vertical curricula". The last of these refers to the fact that students in our disciplines often have to "slog" through a bunch of introductory skills courses before they are ready to do the intersting work of science.
While Chad teaches at a small private college, my experience here at a mid-size public university seems to match with his. We don't have many large sections in computer science at UNI. For a couple of years, my department experimented with 100-person CS1 sections as a way to leverage faculty expertise in a particular language against our large enrollments. (Irony!) But for the most part our sections have always been 35 or less. I once taught a 53-person section of our third course (at that time, object-oriented programming), but that was an aberration. Our students generally have small sections with plenty of chance to work closely with the tenure-track faculty who teach them.
We've never had a weed-out course, at least not intentionally. Many of our students take Calculus and may view that as a weeder, but my impression from talking to our students is that this is nothing like the brutal weed-out courses used in many programs to get enrollments down to a manageable size of sufficient quality. These days, the closest thing we have to a weed-out course is our current third course, Data Structures. It certainly acts as a gatekeeper, but it's mostly a matter of programming practice; students who apply themselves to the expectations of the instructor ought to be able to succeed.
The other two issues are problems for us. The average GPA of a computer science student is almost surely well below the university average. I haven't seen a list of average GPAs sorted by department in many years, but the last few times I did CS and economics seemed to be jostling for the bottom. These are not disciplines that attract lots and lots of weak students, so grading practices in the departments must play a big role. As the Inside Higher Ed article points out, This culture of grading is common in the natural sciences and the more quantitative social sciences at most universities. I don't doubt that many students are dissuaded from pursuing a CS major by even a B in an intro course. Heck, they get As in their other courses, so maybe they are better suited for those majors? And even the ones who realize that this is an illogical deduction may figure that their lives will simply be easier with a different major.
I won't speak much of the other problem area for us, because I've written about it a lot recently. I've never used the word "vertical" to describe our problem of boring intro courses that hide or kill the joy of doing computing before students ever get to see it, but I've certainly written about the issue. Any student who graduates high school with the ability to read is ready for a major in history or communication; the same student probably needs to learn a programming language, learn how to write code, and figure out a lot of new terminology before being ready to "go deep" in CS. I think we can do better, but figuring out how is a challenge.
I must point out, though, that the sciences are not alone in the problem of a vertical curriculum. As an undergraduate, I double-majored in CS and accounting. When I switched from architecture to CS, I knew that CS was what I wanted to do, but my parents encouraged me to take a "practical" second major as insurance. I actually liked accounting just fine, but only because I saw past all of the bookkeeping. It wasn't until I got to managerial accounting as a junior and auditing as a senior that I got to the intellectually interesting part of accounting, how one models an organization in terms of its financial system in order to understand how to make it stronger. Before that came two years of what was, to me, rather dull bookkeeping -- learning the "basics" so that we could get to the professional activities. I often tell students today that accounting is more interesting than it probably seems for the first one, two, or three years.
Computer science may not have moved much faster back then. I took a one-quarter CS 1 to learn how to program (in Fortran), a one-quarter data structures course, and a couple of courses in assembly language, job control language, and systems programming, but within three or four quarters I was taking courses in upper-division content such as databases, operating systems, and programming languages -- all of which seemed like the Real Thing.
One final note. I actually read the articles mentioned at the beginning of this essay after following a link from another piece by Chad, called Science Is Not a Path to Riches. In it, Chad says:
A career in research science is not a path to riches, or even stable employment. Anyone who thinks so is sadly deluded, and if sure promotion and a fat paycheck are your primary goal (and you're good at math), you should become an actuary or an accountant or something in that vein. A career in research science can be very rewarding, but the rewards are not necessarily financial (though I hasten to add, I'm not making a bad living, either).
This is one place where we differ from physicists and chemists. By and large, CS graduates do get good jobs. Even in times of economic downturn, most of our grads do pretty well finding and keeping jobs that pay above average for where they live. Our department is willing to advertise this when we can. We don't want interested kids to turn away because they think they can't get a job, because all the good jobs are going to India.
Even still, I am reluctant to over-emphasize the prospect of financial reward. For one thing, as the mutual fund companies all have to tell us, "past performance is no guarantee of future results". But more importantly, intrinsic interest matters a lot, too, perhaps more so than extrinsic financial reward, when it comes to finding a major and career path that works. I'd also like to attract kids because CS is fun, exciting, and worth doing. That's where the real problem of 'verticality' comes in. We don't want kids who might be interested to turn away because the discipline looks like a boring grind.
I hope to learn more about this systemic problem from the empirical data presented in Talking About Leaving, and use that to figure out how we can do better.
Now that the issue has been resolved, I can finally write on a topic I mentioned three weeks ago, my department's proposal to create a new major in Software Engineering. This is one of those persistent "interruptions" this summer that really was an important task in its own right. It also reminds us all that academic politics are a non-trivial exercise.
A couple of years ago, the faculty in my department decided to propose three new majors. One, bioinformatics, targeted an area of growing importance in which computing is an essential component. Graduate programs in bioinformatics were becoming common at this time, but few or no undergraduate programs existed. We figured that this major would attract a new audience of potential students and capitalize on the strong math and biology departments here. The other two proposals were extensions of the standard B.S. in Computer Science program we already offered: Software Engineering, and Networking and System Administration. These proposals targeted particular professional areas that our students pursue within our existing majors, giving them a little extra heft and their own identity. We figured that these majors would allow current CS students to choose a major that more directly matched their professional careers and hoped that they would attract students interested in these areas who might otherwise not attend our university.
Such "targeted majors" are becoming more common throughout the country, and we hoped to be in the vanguard. Personally, I'm not a big fan of "superset majors" like Software Engineering and Networking, because I think even our most professionally-oriented students are best served with a broad CS major that prepares them for a diverse and dynamic discipline. But I do understand their appeal to students and thus their utility as marketing tools. Add to this reports such as Iowa's Information Technology Strategic Roadmap, which recommends focused majors as tools for developing the state's base of IT workers, and such majors become even more attractive to the university. At a time when our discipline is changing, such majors represent a reasonable effort to broaden and focus our reach at the same time.
In order to create a new major at one of Iowa's three public universities, you must have it approved by the system-wide Board of Regents. Before a proposal reaches the Board level, though, it first must receive approval from the provosts at the three institutions. This is a reasonable mechanism which generally ensures that all of the universities know what the others are doing, helps identify opportunities for collaboration, and prevents unnecessary duplication in programs.
Our bioinformatics and NaSA proposals were approved in the initial proposal cycle, but software engineering was not. One of our sister institutions raised objections to all three proposals, but the other gave us its blessing. As part of a compromise to overcome the objections, our administration withdrew the Software Engineering proposal from the table. This succeeded because, while the objecting school would have preferred that we not offer any of the new majors, its greatest objection was to the Software Engineering proposal. This objection ultimately came down to our use of the word 'engineering' in the title of a degree program. The other schools have Colleges of Engineering, but we do not.
Engineers take use of the word 'engineering' quite seriously as a matter of professional honor. To them, engineering means something specific, and engineering education requires a specific set of courses in mathematics and the physical sciences, as well as specific experiences rooted in how professional engineers craft their trade. My university does not offer a traditional engineering program, so our engineering colleagues do not consider us capable of offering an engineering major.
So we passed on our Software Engineering proposal and put our energies into launching the other two new majors. They've now been on the books for a year and have begun to attract majors. We've also experimented with professional marketing techniques to introducing bioinformatics to our target audiences.
By the time I became department head, we had a new dean and a new provost, and our faculty really wanted to re-propose the Software Engineering major. The faculty did not feel that the original proposal had been dismissed on its merits, but rather for political reasons, and they wanted the chance to make their case that we be allowed to offer this new major, which so closely aligns with the professional goals of many of our students.
So we set out to educate our new administration on the discipline and why our university should be offering degrees in software engineering. Once they were convinced, we took our case back to the council of provosts. Not too surprisingly, we encountered the same objection.
Actually, we encountered several objections. Since the time of our initial proposal, the objecting school had proposed its own Software Engineering degree program. So now there were concerns about duplication of effort and resources. Those of you on university faculties surely know that duplication among state schools is a big issue these days. State funding isn't as plentiful as it used to be, and so unnecessary duplication is viewed as an unacceptable financial luxury.
Another objection involved the fact that we did not intend to seek accreditation of our program by ABET, the standard accrediting agency for engineering programs. As a matter of professional standards, nearly all traditional engineering programs are accredited by ABET. Software engineering programs are a relatively recent phenomenon, as is their accreditation. Programs started within colleges of engineering do tend to seek accreditation, but not all do. A considerable number of undergraduate software engineering programs -- about a quarter of the thirty programs currently being offered in the U.S. -- lie outside of an engineering college and are much less likely ever to seek accreditation.
This might be a concern for the established engineering disciplines, but I think it is less of an issue for software engineering. I'm not sure we know how to "engineer" large software all that reliably yet, and I'm not sure that we have a good sense of what all software engineers should know or be able to do. Projects such as SWEBOK are valuable efforts to catalog our current understanding, but what we really need is many more years building big systems and examining our practices along the way.
This brings us back to the semantic issue that lies at the heart of the objections to our program proposal. Our engineering colleagues consider software engineering to be an engineering discipline like mechanical or electrical or civil engineering, and as such they think it should be treated like the traditional engineering programs. Whatever the professional assessment of engineering colleges regarding the use of the word "engineering", the term "software engineering" is widely used throughout the U.S. and the world in a broad sense, to describe the disciplined construction of software systems. Courses in software engineering are offered by many different academic institutions, including the majority of Computer Science departments these days. Graduates of computer science and information systems programs move immediately into positions with the title "software engineer" in many different kinds of companies. For our students, these employers ranges from traditional engineering companies to financial services companies such as insurance companies and banks. Many small, independent software developers consider themselves to be software engineers, though they would never consider becoming a licensed professional engineer. Standard use of the term "software engineering" does not indicate "engineering" in the sense understood by the engineering profession.
Perhaps it should. Our colleges of engineering would prefer to define the term prescriptively, setting standards and ensuring that anyone who bears the title of engineer meet a set of common standards first. This is a noble aspiration. But my definition of the term is descriptive, in the sense of describing how it is used by people out in the world. In this descriptive sense, I think it is perfectly reasonable for my university to offer a Software Engineering degree.
Alas, I am not the one to make this decision. Our sister institutions persisted in their objections to our proposal, and so again it failed. Had we changed the name of our program to Software Development or almost anything else without the word 'engineering' in it, we would probably have succeeded in having our program approved. Our faculty decided that to change the name of our program to something non-standard would defeat the purpose of offering a specialized degree in the discipline; it wouldn't match up with the expectations of students or the companies that hire them. Besides, the non-standard name feels distinctly sub-standard, as if we aren't capable of offering a degree in the discipline that folks have come to regard as standard in industry.
Sadly, I fear that there may have been an element of this thinking in our sister institution's objection to our proposal. They think us worthy of offering an "applied computer science" program in something called software development, but not worthy of awarding degrees in Software Engineering.
I work at a so-called teaching university. While most of our faculty is engaged in research and other scholarly activity, basic research is not our mission; producing well-educated citizens is. A computer science program at a school such as mine blends a solid core of empirical CS with what amounts to professional education, not all that different from the pre-professional programs we offer students interested in pursuing law degrees and medical degrees. For most of our CS students, computer science is a professional degree, and software engineering is one of their professions of choice. One of our goals is to produce broadly educated practitioners in a discipline that changes rapidly, while at the same time changing the world in which the practitioners practice.
Ultimately, I think that our position on who should be teaching software engineering will be proven right by history. While I am not a big fan of the metaphor, software engineering as a discipline is much bigger than colleges of engineering conceive it, and more and more schools will teach it. In the meantime, we will continue on with what we have -- a B.S. program in Computer Science, with a Software Engineering emphasis -- and prepare students to enter the world ready to develop software, including the largest of systems, whatever that activity may be like in the future.
I sit hear now wondering what software engineering programs in colleges of engineering and think about agile approaches to software development. Maybe we are lucky not to be constrained by the straightjacket of expectations that accompany the programs in established engineering disciplines. We are still learning how to build software, and we can fold our learning into our courses and curricula much faster when we don't have to worry about a set of restrictions based in other engineering disciplines.
Anyway, for those of you who think that "office politics" in the "real world" make life worse than it is in the ivory tower, this little story only scratches the surface of what university politics are like. That's a whole other story...
My blog has received occasional interest from unexpected places, such as my local newspaper and the author of a book on marketing. These contacts have always been pleasant surprises. Yesterday evening, I received e-mail on a different sort of interest, one which is less pleasant.
In a blog entry on June 14, 2005, I did what I sometimes do: use an image or cartoon from another source that illustrated a point I was trying to make. In this case, it was a cartoon from a well-known series that expressed humorously how I felt when accepting the position as head of my department. I wanted to give the creator credit for his work, so I mentioned it by name and linked to the author's web site.
Somehow, the syndicator of the series came to know about my entry. (The fact that my use of the cartoon shows up as #40 on a Google Images search for the cartoon makes the discovery not all that surprising!) Last night, I received a polite letter from the syndicator asking that I remove the image, along with a playful though perhaps overwrought message from the author himself. I updated that blog entry as soon as I could to remove the offending image.
As I said, I occasionally use images from other web sites to illustrate my blog, though I have not sought official permission to use all of them. I've always tried to stay within the bounds of fair use, and I have always linked to the web page where I found the image, so that the creator would get full credit for his or her intellectual property along with any attendant traffic that may follow from my readers. In an "free software" sense, I was just trying to participate in the exchange of ideas.
I may well have been within the legal bounds of fair use in this case. Not being a lawyer, I would have to spend a little time, if not money, to obtain a legal opinion to that effect. In either direction, I do not think it's worth my time or money to find out.
I have great respect for intellectual property rights and do not wish to infringe on them. I recall being rather annoyed by the cavalier attitude taken by the founder of Wikipedia on the its use of copyright images and images otherwise controlled by others. Whatever one feels about free software and open source, one rarely has the right to require another person to share intellectual property. Similarly, the idea of downloading copyright music and video without paying disturbs me. I may think that someone should distribute something openly, but that is the copyright holder's prerogative.
So: I will be careful from now on to use only those images for which I have permission to do so.
Last week, I quoted Bob Martin on the interplay between design and building:
You always have to design something before you build it. The question is: "How much do I have to design before I build?" ... the act of building is *part* of the act of design....
To many people, this sense of design is heresy. They prefer a more formal definition, one that makes clear a distinction between between design and implementation, and analysis and design. Even in a day where iterative models of software development have replaced the waterfall model in the minds of even the most traditional software engineers, many people still think of the phases of development as very different.
Agile software developers seek to iterate more quickly through the phases of software development, in large part because of what Martin reminds us: we learn too much about our design from writing code to wait very long to begin writing code. Likewise, we learn too much from our design and coding about how well we understand our problem to wait very long to begin designing and writing code.
So, what is the best definition of design for us to use in our work, and with our students and new hires? Folks who see the phases of software development as Major Events to be seen as separate activities are most likely to give Major Definitions to the phases. But I've learned a lot about design from folks who have more pragmatic takes on software development.
Sometime last year, the members of a mailing list I'm on discussed the definition of design. Jim Coplien and Grady Booch gave very thorough definitions of design, both the verb (the act of designing) and the noun (the artifact produced). Both of their definitions incorporated the idea of a system and its behavior, related to the forces that exist in the system's intended environment. The thing I liked best about Booch's definition was how it managed to account for the scientific side of design, where empiricism and experiment help us to make optimal decisions in a large search space, as well as the artistic side, where science leaves enough degrees of freedom to enable clever and elegant decisions.
Whatever else design is, it is about the choices we make while building things. Some of the features of a system are required by the customer, and others are driven by the technologies that we use, including the programming language. The rest of the system is determined by the developer. This is how James Noble characterized design in our e-mail discussion: the decisions we make that determine the rest of the system.
By the way, Noble's definition reminds us just how important it is not to use an overly restrictive programming language when we build systems. Such a language makes too many decisions for us upfront, without regard the problem we are solving or the environment in which the system will live. Choosing such a language surrenders too much freedom, too much possibility, too soon.
Once we get to the point of seeing design as being about choices, and without any predisposition to create a complex definition in order to distinguish design in some formal way, we can get to my all-time favorite one-line definition of design. This definition is courtesy of Ward Cunningham, whose gift for simplicity I have extolled before:
Design is your choices that stick.
This brings us back to the fundamental truth in the agile approach captured by Robert Martin in the passage above: Not all of our choices will stick, and we need to learn which will and which won't as quickly as possible, from whatever sources we have available. And that includes the program itself.