“3 credit course my ass”, they say.
As a Computer Eng. student, I took ECSE-211 in Winter 2019. I thought taking this course in winter would be less stressful since we get the reading week. I guess it was.
I have to mention that many people didn’t like the course, but they enjoyed it. Yes, it sounds funny, and that’s my observation. I must say cognitive bias does make things feel worse than they should – I came in without knowing what this course is about, and overall I think it was not that bad.
What Went Bad
Design Principle and Methods – that sounds like a theoretical course, and it is. Alongside with the lecture about the design process, i.e. documentation 101, we also had a lab. Just like circuits courses. For the lab, we were asked to build a robot using this LEGO Mindstorm EV3, along with a custom firmware (LeJOS) so that the software side could be implemented using Java – McGill’s (and perhaps worldwide universities) standard language.
The thing is that we basically have 6 different robots to build, and that seems to be a bit misleading; since the first 5 labs involve little to no design principles and methods (documentation and/or “designing disciplines”), people tend to be fooled that robotics is the central part of the course, i.e., full mark in each lab.
That gives rise to a significant issue in the DPM lab – quite a lot of groups had no organizational structure whatsoever. A lot of no-plan dirty work was apparent because people are just concerned about getting the thing to work before the deadline. I admit that I was in that boat also.
Here are some examples of what went wrong (including mine & other team’s)
- Quite of a famous option among Electrical-Software pairs: builds hardware (usually dodgy), starts writing software, then one person suddenly decides to change the hardware to something significantly different, then basically rewrites the software.
- What’s worst: in the end, one person gets them all because another person is not really thinking.
- But not reporting your teammate because you don’t want to write a report.
- E-mail zip files of the source code to collaborate
- Come on, we live in 2019
- Copy-and-paste folders for “version control” (and then messes up the number and forgets which one is which)
- Your team finished lab 4, but your partner still doesn’t have LeJOS plugin installed on Eclipse
- Writing Javadoc without even thinking “what’s the point of this thing” because “TA says so”
- Those people thinking the software is “versatile” (i.e. assuming the hardware is always perfect)
- At the flip side, it means they believe “software can always fix the hardware defect” – I saw some very religious software students…
- That could kill people.
Does DPM have a practical component in the course? Yes. Is that the main point of the course? Not really. And so these “engineering disciplines” were not really covered in the lecture. At least I didn’t really see it from the lecture. I don’t seem to find an appropriate way to “lecture” these kinds of stuff, though.
Reflection: What does it mean by “leader”?
In larger group for the final project, there are project manager, documentation manager, hardware leader, software leader, testing leader, and a joker.
It’s unfair in the sense that EE students only take ECSE202 before this course, while SE or CE students have probably taken/taking ECSE223 or ECSE321 – courses that involve team software development. So it’s quite natural for SE/CE student to become a software leader. That ensures things to go well, right?
Regardless of who becomes a software leader, it seems to be an attractive option for the “software leader” to do most of the coding by him/herself. That allows a team to begin with the software component from a very early stage – even if the design is not ready yet. At some point, the design is finalized, but the code is already very messy (unused/irrelevant methods there, etc). The software leader then tries to finish most of the code by him/herself.
At the worst case, such option may lead to being blamed by others if things are not working, start blaming others not contributing, getting pissed off, etc, etc.
I was a testing leader, but that was a moment to reflect on what does it mean by a “leader” in the engineering project. Since this is a blog, I think it’s a good idea to write it out here for myself to reflect on it in the future. This is for a software leader but should be applicable to any other leadership role.
The software leader should be able to produce a big picture of how the system is going to look like, i.e. the abstraction of the system. Then, this person can start to plan the smaller components of this system – i.e. specific methods and how to integrate them. This makes the picture to be clear and sharable with others in details. Consequently, the entire development team can collaborate on a single system, without confusion, because the leader can create and distribute the task (e.g. a method/class).
After all, for me, DPM was about how to collaborate by being organized. I think.