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.





いろんな形のMifare Classic 1k (S50) のNFCタグを買いました。

基本的に、流通しているS50タグには4バイトのユニークなID (UID) が割り当てられていて、普通のカードでは書き換えができないらしい。大したセキュリティが必要ない会員カードとかでは、このUIDを鍵として認証用に利用している所が多いようです。

・・・が、UIDが保存されてるブロックが書き換えられるようになっているチップもあるみたいで(^_^;) それは二枚だけ買ってみました。上の画像の左下の二枚がそうで、交通カードをクローンして携帯電話に埋め込んだりするために、0.5mmくらいの極薄カードになっています。