Noteworthy Points about my Courses
· Studies show that those who do not attend lectures do not perform as well as those who do. My own experience is the same.
· My lecturing style and in-class expectations:
o I shall share with you what I know from the literature and from my own experience. I may differ from what a book might say and will let you know of the exceptions.
o A lecture session is a two/multi-way street. Based on the points being discussed, two (or multi) way interactions lead to better learning for all. Participate, participate, participate!
No question or response is stupid.
Rather, silence on something you would like to, but (for some reason) are afraid
to, ask is (really) your loss – and the whole class’ loss too. PLEASE ask in the
o If I do not know the/an answer to a question, I shall let you know and shall try to obtain the answer from external sources.
o I tend to give many examples on the points being discussed. These are most often “not” to be found in books or found with difficulty in the literature. Often, they are based on personal experience from collaborative projects with industry, from other disciplines, or simply common sense. Quite often, these examples are not described in the presentations slides. Some students have told me that anywhere between 30-60% of my lecture content will not be on the slides or course text. Some material is rooted in latest or recent research or research projects.
o I expect students to “get into it” when examples are being discussed. Those who do tend to perform better than those who do not. Some students do “not” like this approach; some do. While at times a given slide might take long to get through, my considered opinion is that students need to know what is being transpired; it gives them broader knowledge AND “understanding” of the issues in software engineering.
o Admittedly, different students work or absorb at differing rates. That is why there is “enrichment studies” for those who want to take up this challenge. It is a heft bonus!
o The objective in my course is “not” to rush through the slides/material; it is to learn as much as we can given the time we have, class configuration we have, and collective experience we have. This varies from year to year. Otherwise, you might as well do an on-line, remote learning course on your own. Software engineering is “not” a pencil & paper exercise in a lab; we, as a society, increasingly depend on software, much like air, water and heat. We need to talk!
Research and pedagogy are integrated as much as appropriate. That is,
o Try to ask the following with every point (the “WHAT”) being made – as appropriate:
§ Why, Where, When, Who, How, Implications on other types of artefacts and other project variables (listed here), Cost, Quality, User/Customer satisfaction and issues, Performance, Tools involved, Processes involved, Time, People-roles, Product representations (not only code!), Technical vs. Managerial vs. Governance issues, etc.
o If you happen to come late to a lecture, please be considerate of the others. Slip in silently without disturbing others. Likewise, if you want to leave the class early.
· The best time to catch me is generally right after the lecture.
· If you must phone/email, please contact the TAs first for a faster reply (but send a copy of your email to me so that I am aware of what is going on and can catch things falling in between the cracks). I am usually swamped with emails from worldwide, teach several other courses, supervise graduate students, have many other responsibilities and, therefore, my responses will most certainly not be immediate. If you are desperate or things are rather “urgent”, then just catch me right after the class. You can also try my office but please note that I am not always in.
· I expect that you will have read the lecture material BEFORE you come to the class. See the course outline for the material to be covered in the course. Those who do perform MUCH better then those who do not.
· Those who read other sources for the material on the same/similar topics generally perform better than those who do not. Those who have practical experience in the relevant topics also generally perform better then those who do not have such experience.
· Those who perform well in my classes generally have realistic or plausible EXAMPLES for virtually any software engineering point or issue. Think deep, read diverse sources, talk to others, and experiment with technologies and case studies. You generally cannot know all there is to know only by attending the lectures.
Studies show that “active learning” leads to
better performance than “passive learning”. So, take the notes down in the
Start your assignments and projects immediately, if you want to perform well in my
· Have an EXPLICIT TIME-MANAGEMENT agenda. Be guided by it. Cannot over-emphasize this!
· Try to turn your time agendas around to see what works best for you. For example, working during early hours in the morning, when your mind and body are well-rested, might work much better than staying up late at nights when the mind and body are tired from the day’s activities.
· Finally, I sincerely would like to help you succeed in my courses. If you have issues that are affecting you in the courses, please come and talk to me. We shall try to work around these issues as much as is reasonably possible.
Many students leave it till way too late for me to be able to help them. This is extremely sad. I know in many such situations that I would have been able to help them and their lives would have been much better. This is just very sad.
· If you have learnt things in my courses and, consequently, do well, then this is a BIG achievement for ME. Why we met here in this life, only God knows, but I consider this as MY privilege to be the custodian of this course in which we play different roles. We are all in the same boat, just remember that. We are sitting in different places in the same boat – that is all.