Design Principle and Methods?

“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?

Not really.

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.