If you ask a computer science major what class they dread the most, or what class they hated the most, chances are they’re going to say that they were not a huge fan of Software Design and Documentation. The reasons for this vary, but the general consensus is the same: it’s just not a good class in its current form.
But it’s a necessary class. In the entire computer science curriculum, it’s the only one that’s communication intensive. Also for any computer science major (even if you’re doing theory), being able to communicate well is important. If you work in the industry, then you have to pitch your project ideas to the higher-ups to try and even get the chance to work on it, not to mention work well with a group (more on this later). If you go on with theory or research, presenting your ideas is still important, not only for getting funding from various sources (like the National Science Foundation), but also for attracting students to your lab or research group. And if you do end up doing research, chances are you will want your work to get published somewhere relevant or get into the relevant conference of your field (like SIGGRAPH) where you will present your work to hundreds, if not thousands, of people. Let’s face it, most computer science majors aren’t the best people in front of crowds, nor the best writers. This is a chance to practice a skill necessary for success later, no matter where you go. When push comes to shove, great work can be meaningless if it’s not presented well.
Software Design and Documentation is also the only required class in the CS curriculum that has mandatory group work throughout the entire semester. Yes, there are other necessary classes that require group work like Operating Systems and Computer Organization, but those are small groups (only two people, sometimes three) working on small projects. In the real world, you’re going to be working on large projects with a larger team. I know that many of CS majors would prefer to work alone, but trying to get a massive project done on your own just isn’t feasible sometimes. So SD&D gives you the chance to work with a larger group (four people, sometimes five) on a project of non-trivial size: this shouldn’t be a project that can be completed in one semester by one person and still have time for the rest of his or her classes.
Despite thinking that SD&D is necessary, I still think that the class isn’t exactly the best in the world. But in its current form, the class is just too much rolled into one. It’s the computer science capstone course, the only communication intensive course, a CS major’s introduction to software engineering, and it’s also the only course requiring significant teamwork. The class just feels like it has too much to do, tries to do all of it, but can’t.
So what needs to happen to it? The solution that I like the most is to split the class into two different courses: an introduction to software engineering course and the capstone course. The software engineering course would teach all of the design principles and patterns currently taught in one semester without the overhead of the semester project. Assignments could take the form of having to present a pattern to the class (as students currently have to) and having to implement (at least in some form of code or pseudo-code) several of the patterns. The course would also cover different methods of development (such as agile) and the basics of working with a large group (version control and other relevant topics). The capstone course would simply be the semester project under an advisor, and a chance to apply what students learned in the software engineering class. The class, as a whole, would meet several times during the semester. During these meetings, each team would give a presentation on their team’s project’s current status for a minimum of 10 minutes. The first couple meetings would simply be a project pitch where people could pitch project ideas and form teams around these ideas. Teams would be assigned a mentor from a pool of professors or adjuncts in industry who are knowledgeable about the software development cycle. These advisers would simply be responsible for making sure groups assigned to them stay on track and move forward as the semester progresses. They would also help groups with any problems the group has with the development cycle.
Of course, there are other solutions out there. Everybody knows that SD&D is not a very well-liked class and hopefully we’ll start to see changes soon. Obviously, changes that happen won’t impact me at this point, but hopefully others who take the course will enjoy it and help SD&D lose its bad reputation.