FREQUENTLY ASKED QUESTIONS
Updated 2024-03-30
First, a note about teaching approach. This is a capstone course, which on this campus demands a broader set of learning objectives than sought in most of the ordinary 400-level CS courses. This also means we presume everyone brings something to the game. Our mission is to create opportunities to integrate prior content, not just pick up new content. We employ teaching practices that ensure all students passing 435 evidence the basic knowledge, skills and attitudes appropriate to our engineering profession.
We presume everyone studies the support materials (textbooks and select web sites) to learn about software engineering in the abstract. The project is where we apply and try what we study, and at the same time this gives us the "evidence" just mentioned. Class is when we discuss how to connect the abstractions and specifics; time together is a guided reflection in the technical activity. We compare nuances of our respective projects and relate them to the field. While the weekly pace will vary, typically one scheduled lecture slot will be dedicated to such exploration, and the other will be used for lab (whether applied exercises or just guaranteed team time).
One challenge for many 435 students is adjusting from previous course formats based on a crisp rubric ("check all the boxes, win a prize!") to a format based on the expectation that students must create a road map for success. (That's the "integrate" part. Sorry. You need to think.) Not everyone handles ambiguity well at first, but any student who exclaims "just tell us what you want us to program!" in frustration should reflect on the fact that the real decisions are baked into that "what". In 435 we figure out the "what" to predictably solve the problem at lowest cost. We can't teach how to create a plan by giving you a plan. ("Here, just do this." -- that's the way to learn how to program my project, not learn practices necessary to take ownership of your project.) The sooner everyone embraces this reality and exercises a bit of initiative, the better we'll all do.
Do you post class slides? No. As noted above, the best use of our time together is for discussion, not to have me stand before you reading content which you could just as easily have read for yourself. Slides won't carry that content as well as the texts, nor will they be tailored to your specific projects, which is the point of mentoring in this way. I will often display an outline to keep me on track with discussion, but for full value, please join us in class as a participant, not a spectator.
Why don't we use ELMS? Our course relies support tools which are not available on ELMS. These are instead organized on our own servers. We minimize the number of sites to track by not splitting content with ELMS. This also has the benefit of minimizing (just a bit) how much our students are placed in a stream of commerce as consequence of taking classes here.
Why not post quiz dates in advance? Our quizzes are not deep. Each is a very fast drill done at the start of a class to give emphasis to points made in the prior discussion and also underscore practices we should have been following all along. We don't post dates since we probably don't know we will offer one until we arrive at class and discover that students need a reminder of the business value of following basic practices (one of which is showing up on time to participate.) Must be present to participate.
Can we use outside management tools for projects? I hope you will! Trello, Jira and so many others all serve important functions; choosing tools as a team, then discovering with what good or bad effect, is one of the many steps you'll take on the way to solving the problem. Just remember, these do not replace the obligation to use the ticket system managed in class. Tickets in outside servers reflect team consensus, however the tickets in 435's servers log individual observations, captured contemporaneously. As with any ticket system our tools might log objective developments (decisions, agreements, mileposts and so on) and as such might partly duplicate data in team systems. However our system is also to enable capture what you think. We want to know your decisions and your views about the team. Why? These are used in the final exam, which is the ultimate reflection on your 435 project experience.
(Please read this paragraph. It is pretty important.) We learn by making tech decisions and then seriously assessing their effect. The final exam is my evidence-based way to know that you reached the learning objectives; I can sign off that you got there (and pass) by observing your journey of discoveries through the semester. So far so good? Now, my determination can't be based on fiction. Nobody is free to manufacture history for purposes of the final; all assertions must be objectively supported by the record. If you never captured what was in your head early in the project, then you can never credibly explain the revelations or effects later in the project. You might have had great experiences, but if they are not written down to be checked, then we lack the evidence needed to sign off. It is this simple: the final exam is essentially an explanation of outcomes that is created by cut/paste out of text you captured in our system throughout the semester. Use it to connect the dots. Relying on tickets from another team member is not credible. How does anyone argue they learned by explaining what was in the head of some other person? Neither is a dump of data into your log at the end credible; that tells what you want to have been in your head retrospectively, not what was really there. Actionable information: play the game to pass the class.
Why Subversion instead of git? There are a couple good reasons. Both are fine revision control tools but they solve slightly different problems, and chiefly we're focused on solving the kinds of problems that are better handled with Subversion. (We'll talk a lot more about this in a lab, but as a spoiler: git is great for distributed development among people who will occasionally synchronize when features seem fully worked out, whereas we are intent on learning about finer-grain collaborative practices, which is a place SVN can shine.) Another sufficient reason is that we can run Subversion on our own servers where the repository churn gives us yet another good perspective to project activity. (We're engineers ... we measure stuff.) Git hides much of that activity, meaning managers and mentors risk running blind. So I understand - many students already think we know how to use git and would prefer to stick to what is already familiar. But let me point out, this is college, where people occasionally learn new things. In particular SE involves many different dependency models and dev processes than those underneath git, and I'd like for students to reach a point where we can articulate differences as technical matters, not just as personal preferences. Humor me: play the game to pass the class. (And who knows? It might just work!)
Can we select our own projects? Yes, with some planning! I invite everyone to bring their ideas, passions and interests to the table, and registered students know I make this offer well before start of the semester. Not all projects let us reach the learning goals for the course, and vetting projects takes time, but we can't try projects we don't learn about.
No matter how ideas come to us, there's a lot to project selection. We never assign programs to be written, we pose problems to solve. It is up to students to figure out what program might be part of that solution. Which problems serve us? Chiefly we need to know that it will involve grappling with a substantive design challenge; that it will scale appropriately with our team sizes while fitting within a semester timetable; and that we can realistically deploy a solution for use during the semester. That live use is critical. We can't say for sure we reached our teaching goals without closing the loop! Students must be able to see the effects of technical decisions and measure its properties. The goal is not to throw some program over the wall right before end of semester; it is to observe real users accrue genuine value.
We're pretty unlikely to make a flip decision to take on a problem at last minute, especially since this impacts teaming, so sooner is better than later to vet ideas. Bring 'em!
How about team formation - can we work with our friends? Scrimmage exercises (the practice assignments completed early in the semester) are entirely formed by students. Subject only to the constraint of four-students per team, set it up as you like! We hope you use these as an opportunity to meet others too, but this will be up to you.
All other things being equal, we're happy to facilitate teaming preferences with the class project too, at least when when we can. The challenge is that we try to interpolate many other criteria at the same time. Demonstrated skill sets related to a problem area, prior experience with clients in a similar domain, engagement metrics and much more will favor one or another pairing of students with projects. Team sizes may also need to vary (based on cost estimates conducted during problem vetting) in order to balance obligations equitably. I will invite your input but for expediency (and in the interests of offering great project experiences overall) I will define the class project teams.
My friends say 435 is for students who never had an internship. Why take it otherwise? At the risk of offending those who obviously know better than us what 435 is about even without taking the class, please let me assert that 435 is not a replacement for any internship, just like no internship is a replacement for 435. Each has different goals and values, though they relate nicely to one another. Students who never had a substantive internship will learn quite a lot about working in groups, and in fact they might find this is the only course that talks with CS students about how to be an effective team member; when they land an internship or first job, they will be far more powerful. Students who take 435 after an internship - this is the best case scenario - will bring concrete experiences to the table where we can put them into perspective. These students might have learned what to do in some shops, but we will help them learn why it is done that way, and to see what are the alternatives. Again ... more powerful.