Improving Senior Project - A Step by Step Guide
My senior project advisor here at Rose-Hulman has asked for constructive feedback on how to improve the Senior Project for future classes and how to improve the CS/SE curriculum as a whole. This post is my attempt at providing that constructive feedback. In each section, I will first list a problem or criticism and then how I think the situation can be improved. Of course, this is just one set of options, but I did my best to carefully consider the senior project scenario and come up with appropriate solutions.
Making Teams Work
When it comes down to it, forming a team at Rose-Hulman with other students will always be a difficult task. Conflicting schedules, interests, and even sleep patterns can lead to the downfall of a team. Right now, team size is limited to 3-4 people. For most projects, that’s a great number. However, its not just the number that is important when you form a team, its who makes up the team that matters. This is where I think the problem comes in.
CS and SE Are Different
It really boils down to this. At Rose, the curriculum for CS and SE students is different, and I think the desired goals for a person of either major is quite different also. Computer Science majors should be whizzes at software implementation, algorithm design, and the low level implementation details that need to be thought out while you’re in the later stages of a project. Software Engineering students should be prepared to take on more of a managerial and design role in a large project like this. Observing this, I suggest the following team composition rules be established.
- Each team has at least one SE major
- Each team has at least one CS major who is not an SE major (i.e. not a CS/SE)
- The team leader is an SE
Since the capstone project should be preparing students for the real world, we should have people doing what they’ll probably be doing when they leave here. Plus, theoretically, the people get to do what is enjoyable to them for the most part, and work is spread out across interests. SEs will get to do a lot of design and documentation work, as well as managing the process and the team. They would still do implementation, but not as much as CS majors. The CS majors will be code-ninjas who sling stuff corresponding to the process that is being used for the team. They get to eat, sleep, code, and be merry.
The Tools Really Matter, Really!
Let’s face it, the way we manage projects anymore is through software tools. These days, there are a lot of advanced, mature tools that people can use to manage their projects, and I propose that each team be instructed to use one of them to manage their project. Off the top of my head, I can think of two tools that would be a real boon to the senior project process.
Basecamp
This product is produced by a company called 37Signals. It is widely reputed as one of the best project management tools out there, and for good reason. I recently took Basecamp for a whirl and was really impressed by what I saw. Multiple users can be added to the system in different roles (team member, advisor, and client in this case) with specific permissions given to each. Project management utilities include an integrated calendar with an RSS feed, support for milestones, assignable task lists, time tracking, and a wealth of reporting tools.
If students would use this product like they should, by making it a part of their daily routine, the project advisor would be able to see, at a glance, just how well a team is doing. Document milestones could be tagged on the project’s calendar and the actual documents could be uploaded to the site (where they can be tagged as corresponding to a milestone). The advisor could see an effort breakdown immediately by viewing certain reports. Again, its an awesome system, and I won’t try to describe it in detail here… but please see this review of Basecamp.
FogBugz
As an alternative to Basecamp, consider FogBugz. This is a solution from Joel Spolsky’s company, with which Rose-Hulman has an amiable relationship. I’m sure you could get copies for a heavy discount or for free if you asked.
The solution is simple, it is easily adaptable to different process models, and its organized around the concept of getting things done. I really won’t expand anymore on this because I’m sure you’ve read at least a bit about it (due to Joel’s sponsorship of a project this year) but consider it carefully.
Blogs
Each team leader should have a blog. This blog should community weekly (preferably on a set day, like Friday) a summary of the previous week’s progress, setbacks, and lessons learned. Why is this important? It makes a team sit up and recognize the things that it is doing well, the things it isn’t doing so great, and more. Allowing comments would make sure that other teams could try to help them. Provide some type of incentive for constructive comments. Perhaps these blogs could serve as a peer reviewing forum with a topic assigned for an extra blog post on certain weeks. I’m not sure how this would work exactly, but blogs allow for an openness that seems to be the thing to do in business today.
Ughhh…. Lectures
I have learned approximately nothing from the lectures that we have had. While we only have one every 3-4 weeks, I still feel they are unnecessary, and many students don’t get enough anything out of them. My recommendation is to have a list of highly recommended books to be read by members of the senior class. This list should include several things. Here is my proposal for the books to see:
- Code Complete - 2nd Edition
- Design Patterns
- Refactoring
- Patterns of Enterprise Application Architecture
- Dreaming in Code
- One of the many books on testing. Suggest a implementation level book for CS students and a system level book for SE students.
There are numerous others that I could have recommended, but I think this covers the basics of what a student should learn about before coming into this project. I’ve read all of these books because they’re extraordinarily interesting. They’ll make people better developers (which is what we need). Joel Spolsky has said that programmers spend less time learning about their profession then they should, and in my experience here at Rose-Hulman that’s definitely true.
Revamp the Document Grading Model
The document grading model is just not very good at this point. While it has been said that you can turn a document in at any point prior to the actual due dates (mid-term and end of term), this does not provide the proper motivation for teams to do so. Since this is a capstone project that should demonstrate our experiences and what we’ll be ready to do in the real world perhaps we should treat document development more like we would in a business.
First, get rid of every template on the senior project website. Why? The answer to this is simple. A template, for college students, promotes a copy and paste mentality and eliminates the critical thinking that needs to be performed when documentation is being created. Isn’t this critical thinking the important part of the process?
In addition to this, most of the templates currently on the site are outdated and bloated. They copy sections from one another without proper linking. Students get confused when they access the site and see 20 different examples of the same document type. In general, its a complete mess.
Second, actively promote individual thought and formatting of the documents. Meet with the team leader of each team to discuss the documents that are appropriate for that team. Keep track of the decisions made in one of the tools covered above, with a due date for each document. Make the teams accountable by enforcing a rough draft to be turned in 4 days before the due date, to be skimmed lightly by the advisor, and returned the next day so that the team can still make changes.
Third, to replace the template documents, create 1-2 case study-like documents for each document type that will be turned in by more than one team. These case studies can act as good examples of what a document could look like. Make these case studies informative, including not only the actual document, but a brief analysis of the document that promotes its high points and critiques the low points. Do not, under any circumstances, use textbook examples. Find real documents from real companies to use. IBM, Google, Intel, and Microsoft would be nice places to start looking.
That’s It
These are my suggestions for senior project as I see them now. Hopefully this feedback provides some impetus for change in a positive way.