Software Engineering Fundamentals COMP1531 22T2

Thank you for your feedback!

Posted by Hayden Smith 🎉 Monday 05 September 2022, 09:27:39 AM.

Hi everyone!

Yes, it's me, the ghost of COMP1531. I've spent most of today churning through the MyExperience feedback from 22T2 and taking extensive notes (this happens every term). I wanted to spend the time to addressing some of the feedback!

From my rough count, about 1 in 8 students didn't have a very good time this term (to over-simplify it). I really wanted to speak to those student's first and talk a little bit about what happened.

(1) Two major things that impacted the term

Thankfully, this is the 6th time I've run COMP1531, and this helps me get a very good feel for what does and doesn't work. We've experimented with a lot, and I want to start with the two major things that I am confident are the primary culprits for some of the challenges we faced this term.

(1.1) COMP1531 running in T2 for the first time

In 2021 CSE decided to run COMP1531 in T2 (3 times a year). This term was the first time it happened. Running a course in a new term can always have interesting side effects. The most notable one though was that the average competency of a COMP student coming into this course was much lower on average than normal. Normally when someone does COMP1531 they've pretty much always done COMP1521 and then about a 33/33/33 chance they've done COMP2521 before, during, or after. This usually leads to higher capacity for students to step up in challenging situations, and naturally our course has over years trended towards that type of student. For example, typically a student who does 1531 in T1 is actually in their second year.

There is a range of potential solutions to something like this - but they're not short term. Solutions can range from simplifying course content in every term (not the most sound approach) or potentially putting in other minimum requirements to do this course. This is unlikely something I am involved with because it's a bit of a longer term strategic piece, but I more just wanted to canvas that this was a real thing and it had quite a lot of trickle on effects (e.g. students saying that X was too hard when it's never been too hard for student's previously).

Even though we did have a lot of students struggle, I would like to commend nearly everyone for stepping up to the challenge. I think the persistence and ambition shown by so many of you is genuinely wonderful.

(1.2) Just a lot of group work problems

I wouldn't say we had a lot of terrible groups this term, but I'd say we had a lot of normal groups just going through some kind of ordeal. My rough count was maybe 40% of groups were fine/good/great,10% were hellish, and 50% were OK had a bit of a storm at one point or another. Nearly all of these cases came from someone (or multiple people) just simply not doing the work.

Now why is this? It would be easy to scapegoat the preference system, but my experience tells me it's not that simple. I think it's a combination of a trickle effect of (1.1) (above) resulting in people struggling to perform and it impacting others, and then also just a little bit of bad luck. We notice this sometimes with teaching - sometimes different cohorts of students are different and it can be surprising.

For context, we had as many complex "escalations" of group work issues in this term than we did in my previous 4 terms of teaching this course.

(2) Getting into some more details

Alright! Now I want to get into some more granular feedback and let know either what we're doing about it, or if we aren't doing much, why that is the case.

• (2.1) Pipeline failures are annoying
  • Yes, I agree - it is an ongoing conversation with the school.
• (2.2) Labs were too hard or annoying
  • The labs are a huge improvement this term and I'm proud of the team for what they've done, but I am going to restructure the assessment for future terms to have one of those only need 80% of the marks to get full marks things. This will take the edge of those that felt the pressure to do them all. So thanks for sharing :)
• (2.3) Typescript felt a bit useless
  • Yeah, probably was! I've become certain that static typing is an important part of this course (in terms of introducing it), but that doesn't mean our initial attempt was perfect. We also knew that we wouldn't get it perfect, which is why it was quite light in terms of any assessable outcomes. We're going to continue working on this, including making the transition much easier.
• (2.4) It would be good to have a livestream Q&A sometimes throughout term
  • Agreed! Cool idea, might give that a go
• (2.5) There was no leniency on late submissions
  • This one is tricky. We USED to have labs due earlier than they are now, and there would be a late penalty period with leniency. But after much demand for students asking to have labs due later, we ate into the entire leniency period to have them due as a late as possible. So we do our best here!
• (2.6) The project was worth too much!
  • Yeah, maybe. So when I took over this course I think the project was worth 36%. I slowly started moving it up to 50% over terms. There was a strong consensus across the community of staff to raise that up further so we tried out 70% this term - 50% is just too low for the amount of work it is. 70% is either too high in general, or it's just too high for this cohort. We will experiment further (below)
  • For T3 I will be moving it to 60% and increasing the weighting of the exam again. Labs are dealt with in (2.2).
  • As part of this we also usually find ways to trim the work.
• (2.7) I didn't know how to do X and I was told to teach myself
  • This one is tricky...sometimes people say this and we go "yeah fair point" and other times they say it and we genuinely think "it's reasonable for us to expect this of you." This is a tricky part about CS in general. In very early COMP courses you are mostly spoonfed things in very controlled ways. By the time you reach the end of your degree you'll go through courses where you are expected to teach yourself a new programming language. We do our part on upskilling you for this journey, but we don't always get it right, and will continue to reflect and improve.
• (2.8) I felt disadvantaged by my group's size!
  • OK this is another tricky one. I know I've said this a few times. As a general rule the quality of your team members + how you operate as a team is far more of a leading metric of how many people are in your group. A bad group of 5 is much more destructive than a good group of 3. Your tutors look at this closely and balance the scales. If you don't think they have done so for T2 you can always reach out to me.
• (2.9) Because of my bad group, I didn't get a fair mark
  • MyExperience was filled out well before iteration 3 marking was returned and scaling was finalised. So there is a chance feedback here was very in the moment for people. What I'd encourage everyone to do though, is if you don't feel like you were given the correct mark, please reach out to me via email with decisions your tutor has come to that you think are unreasonable. I'd be very happy to take a closer look!

(3) Things we're just changing anyway even without feedback

• Making the transition to Typescript easier in terms of the boilerplate (much easier).
• Tidying up due dates to push student's to learn a bit more before flex week (to avoid flow on effects of not having enough done after flex week).
• Having a more structured check in every week to basically ensure tutors can hold groups accountable (which catches on bad team members earlier). Basically finding ways to clamp down on bad team members sooner
• A deployment video for the lab, not just one for the project.

There was a lot of other feedback that were raising issues that actually aren't "issues" but we might not have been clear enough that there are solutions to these problems, or not clear enough that we fix things behind the scenes for edge cases. We'll get better at communicating those.

And in general I can't address everything people have said - but you can trust I've done what's reasonable with it, and if you want to have your specific feedback addressed by me feel free to reach out any time :)

Thank you for an amazing term. Add me on LinkedIn if you haven't already. I had a lot of fun, and good luck with everything that comes your way in the future :)

Major Project Mark Release

Posted by Hayden Smith 🎉 Monday 15 August 2022, 10:09:18 PM.

Hi everyone,

You will have seen some grades appear on Webcms3 grades tonight. These include:

• Iteration 3 marks
  • iter3_manualmark (/13.5) - the mark your tutor gave your group for non-automarking
  • iter3_bonus (/3) - the mark your group for for bonus marks
  • iter3_finalmark (/30) - the sum of manual mark + automark adjusted for contributions
    • NOTE THIS DOES NOT INCLUDE BONUS MARKS
• Overall Project marks
  • project (/70) - the sum of iterations 0, 1, 2, and 3, as well as the bonus marks
• Figuring out if you've passed already
  
  • total_marks_before_exam (/80) - this is the sum of your labs (/10) and project mark (/70)
    • If you have 50/80 or higher, you have passed the course
    • If you have 40/80, you need to score at least 10/20 in the final exam to pass the course

These marks are subject to change if new information comes to light or mistakes were made in the determinations (happens from time to time).

The highest project mark was 68.5/70~. It looks at a glance like the average mark was around 35/70. There are still some tutors marking classes (they will have emailed you) so I'm not in a position to comment on the overall cohort performance at this stage - we will wait to see what happens those + the exam :)

I have been asked a bunch about scaling. Don't just assume these marks will scale - as I said in the lectures we only apply scaling if the cohort as a whole does very very poorly. It's hard to explain much more at the moment but you'll have to trust that I have done this before so will make sure we're nice and fair!!

If there are issues with your project mark, please reach out to your tutor. Whilst their response won't be necessarily quick, we will be thorough. Don't stress about "marks being locked in" as I have the ability to update marks until something like mid-September, so we have plenty of time if you're a particularly tricky case.

For the final exam, you will receive at email at 8:30am (Sydney time) on Wednesday with instructions!

Hayden

🍉 Week 11 Update

Posted by Hayden Smith 🎉 Thursday 11 August 2022, 08:15:54 PM.

Hi everyone,

Just some quick updates! No emojis tonight, just straight facts :)

• If you need your lab automarking re-run, please email your lab assist no later than 5pm Friday 12th August (tomorrow)
• Your COMP1531 automarking marks will be released on the grades page by 10am tomorrow. We will also push results breakdown to your git repo. If you'd like to have your code re-run because you're unhappy with your automarking results, please make fixes to a branch and share that branch with your tutor no later than Sunday 14th of August @ 11am so that you can start the conversation.
• Your final iteration and project marks will be released on Monday the 15th of August before 10pm.
• The final exam time is going to be 8:30am-11:53am (23 extra minutes). This is reflected on the exam page.

Hayden