MidCourse Feedback
Home Schedule Prime Directives Engineering Log Coding Standards Software Submission Checklist Dr. Hacker

 

In mid-March, I requested voluntary feedback from you on two questions:

  1. What are three things you like about ICS 413/613 so far? Why?
  2. What are three things you wish could be changed/improved in ICS 413/613. Why?

In this page, I would like to show you the feedback (in some cases, excerpted) so that we all have a better understanding of where the class is succeeding and where it needs improvement.  In the case of improvements, I will provide feedback to let you know what I intend to try to do to address the issue.

In the remainder of this document, your feedback always appears as "bullets". Everything else is my commentary. I made minor syntax corrections, and sometimes omitted additional details that didn't seem useful to the whole class, but I have included a bullet for everyone's responses.  

What are three things you like about ICS 413/613 so far?

I have liked the assignments. I think they've been at a good level that is appropriate for me to work at and benefit from.
  
I like the paired assignments because that allows me to work on a larger project and get to know other students better, without being overwhelmed by trying to coordinate schedules with larger groups.
  
I like the engineering log because, if I do it in advance, it allows me to list the things I need to work on. If I do it after the fact (i.e., at the end of the day instead of the beginning), it allows me to recap what I've done and the problems I ran into and needed to solve. Sometimes I remember to start the log first (before working), and also to summarize later to recap the work session.
  
The course is focused on practical ideas and techniques that I can use to become a better programmer. I really envy the students who are taking this as an undergrad or during their first semester as a grad student. I like this because I want to become a better programmer, anything that helps me get the job done better or faster is good.
  
Class is not boring. The presentations make sense, are relevant, I can see, the lights are on so I don't have to struggle not to fall asleep. None of the problems that I've encountered in other courses.
  
The class web site is great. I love making you do all the work! I just print out the notes. I worry a little that this might reduce the students' engagement (I read somewhere that taking notes helps one to digest new information, and is valuable even if you just throw the notes away immediately), but the fast pace and high relevance of the material probably makes up for it. I would definitely be screaming for you to slow down if I felt like I needed to write down everything you said that was important. So I like it because it helps us to cover more material in a (almost) reasonable way.
  
The lessons learned feedback seems like a really good idea. And this mid-way survey seems like a good idea too, helps you improve, helps me to vent. Get ready for it!
  
Material is very good and very efficient learning experience. Only two month I learned many important software engineering concepts and programming methodology, get an idea of what is good program and what is poor; I learned some popular application JSP, Java Bean and a bunch of tools such as Ant, CVS, Junit and so on.
  
The dry software engineering concept mingled with practical programming practice, which made those concepts easy to be grasped. This may attribute to the above point.
  
Every assignment is hands-on practice project which we have your examples, like stack and stackmvc, to follow. This way, I soon get idea of the model and finish the assignment. BTY, the assignment is not too big and not too small. I like it.
  
The practical approach. It's an excellent way to prepare for career.
  
A range of tools have been introduced which address many parts of the development cycle. I have a sense, because of this, of how the tools fit together and why. I've taken software engineering courses that were theory-centric, and feel that I've gained far deeper appreciation of the issues in the first half of this course than in any other course I've been in.
  
Assignments have focused on tools and process, not on complex coding issues. Courses with a broad coverage area (programming language paradigms, software engineering, AI) tend to try to introduce languages, IDEs, tools, etc in a barrage to the detriment of the students' learning. While the coding assignments in this course have been interesting, they haven't overwhelmed us with "learning the language", and so we've been able to focus on best practice -- proper documentation, data structure selection, build and content management.
  
Your obvious enthusiasm. Not to suck up, but it's been pretty clear from day-1 that you're excited about this stuff, about your work, and about getting other people on-board. I've found myself talking with other students (both those taking the course and those not taking the course) about your -- energy -- frequently. It's refreshing to have someone teaching you who isn't of the belief that their teaching is getting in the way of their real work. I've been watching professors casually signing drop slips these past few days, with little (expressed) regard for why students are dropping their course. Whether I'm right or not, I imagine that you haven't had too many drops.
  
On a similar note (I know, a fourth item....) you're the only professor I have this term who has bothered to ASK these questions. That impresses me.
  
Java Programming convention. When I worked in a company before, we had programming conventions but nobody followed them so that the company did not run well (It's one of the things that the customer always complained about). You spent valuable class time on this and required us to follow it exactly. I think it's wise and worthy.
  
You are teaching the cutting edge technology. It's super helpful to students have no working experience.
  
Demo/Imitation of Stack/StackMVC. It gives us a direct feeling of how our projects look like so that most people are clear on what to do next.
  
We're not in the "Hello, world!" category any more. This class takes our Java Programming ability to the next level. We are not learning Java specifically, our task is bigger than that. Our task is to put together everything that we have learned and things we are learning into a useful software development. I like that. It is not only interesting but, it is seems to be a "Real world" task.
  
"Hello my name is..." Meeting and working with different people, different programming styles, different personalities, and different motivations have been a real educational experience. And it seems to be a taste of what is to come when we hit the work force. Extreme Programming is something that I now believe in. It is an excellent approach to team programming. It just makes programming more fun and educational.
  
Dr. Hacker, of course. Dr. Hacker aka Dr. Johnson, has made this class interesting. His curriculum has us learning something new and interesting every class. Most importantly the things we learn, we are using them in, which is a rarity in our so far theoretical ICS career. A lot of credit must be given to Dr. Hacker for sticking with Java, and coming up with a curriculum that actually works.
  
I like the way you teach and conduct the class. It gets me motivated to learn as much as I possibly can and believe that I can become a better programmer.
  
So far, I like the group assignments. I can learn how other people use Jbuilder and how they program.
  
I like learning all the different tools like Junit and ant. At first it's a little annoying, but after learning just a little, I can see how useful it can be.
  
First thing is that, when those concepts and projects came to me, it seemed impossible to do it, but finally we could really do it. Those things are complex. But you really have an excellent teaching skill that makes us understand and accept in most possibly easy way.
  
Second, your talented teaching style makes the course amusing and interesting. Otherwise, I may easily fall into sleep at that time in the afternoon as usual.
  
Third, project review and your explain on details really gives me concrete help by seeing how you and other students are doing program, obtaining better and direct understanding, absorbing/adapting better methodologies.
  
Not relying on one specific book. Gives us a chance to find answers other than a textbook.
  
Group work. Gives us a chance to experience how working with people will be like and what problems can arrive from it.
  
No 2nd midterm. Gives us a break so we can relax for a bit. ps: we wouldn't mind if you canceled the final and make the final project the final :)
  
Tools you provides in the class. I can learn as much tools (ant, junit, textbook and so on) to help software development in practical sense as I can. I had thought The Textpad is best for me, but you changed my mind to use JBuilder. This is big change.
  
Actual Demonstration of your tools and its implementation in your class. Even though the side give me a lot of information theoretically, I can imagine what I have to do in my home easily because you give me actual instruction to implement them, using your computer. This style helps a lot.
  
Group work. I can learn what I did not know or what I will never know from my partner. Changing partner in every project helps this.
  
PDF file for each class. I can review what I was taught in the future and can go back to the material I forgot immediately because your PDF is neat and organized.
  
Good learning environment: The class is interesting and fun, It is one of the best courses that I have even taken. The instructor cares more about how much students learn from the class rather than how much points will be deducted if students made mistakes on the projects.
  
Learning method: We can learn a lot from the website resource and know more new technology. More importantly, the instructor teach us self-learning skill.
  
Develop team work skill: We can work with different students and learn their coding style. We can discuss the questions every day and receive answers from instructor every day.
  
I really enjoy the review day sessions. It's really helpful to go over the do's and don'ts of programming while looking at code that fellow students have written. I am happy cause I'm actually getting my money's worth for this class. We have already learned a lot and the semester is only half done. I already plan to come back and take ICS 414 next semester even though I'm graduating this semester. I enjoy doing the work for this class even though it is REALLY time consuming.
  
Using more of the agile development methods rather than the "old-school", boring non-agile methods. This approach is much more interesting and we don't need to plod through months of BORING documentation.
  
Learning material and development that we can directly apply to the real world (e.g. developing web applications that people can actually use.). A lot of this material I can use at my job where I do web development with ASP. I am actually beginning to let my boss know about the possibilities of programming for the web with Java.
  
Learning the proper way to DEVELOP software rather than just making sure the assignment works at the end. I am able to make the code maintainable, thereby allowing the project to possibly continue and evolve instead of finishing the assignment and I never touch it again.
  
Lecture. It is interesting.
  
Project and Engineering Log. They are brilliant ideas.
  
Group work. We can learn from each other.

What are three things you wish could be changed/improved in ICS 413/613?

Ok, here's the good stuff :-).  Since, interestingly, there's a lot of repetition, I'm going to cluster your comments by category and then respond.

Reading assignments and course materials:

The early reading assignments that did not correspond to the material being presented seemed like excess (unnecessary) workload --- i.e., it was not an example of just-in-time delivery/requirements.
  
I think Pfleeger is pretty lame. She puts me right to sleep. And she was expensive, too!
  
I wish there were better study materials for some of the topics. For example, the servlet stuff is really a mess. I like the idea of skipping all the obsolete stuff & going straight to doing it "right", but there is no adequate "JSTL for beginners" document that I have found.
  
The reading materials always overwhelmed me. If it could be narrowed down, therefore key concepts and materials can be separated from optional and complimentary stuff. Then I may have more straight and closer eyes on more important concepts and materials.
  
There is a lot of material to cover. I have the luxury of being able to dedicate more than half my time to this course. I am wondering how the students that carry abnormal load are managing.
  
Time to upload the PDF files for each class. Because I think that learning or skimming the material we have in the class help me understand the material you would teach well. This is very important for me so that I really would like you to upload it at least 2 hours before the class starts (hopefully the midnight before the next day class).

I feel your pain.  From my end, I am trying to satisfy a number of constraints. First, people have widely divergent backgrounds, so it's hard for me to figure out how to "narrow down" the amount of reading, because then I fear that I will omit a paper that some one will learn the most from.  I will try to do better.   Second, I accept that almost any survey-oriented software engineering textbook is going to seem to suffer in comparison to highly focused, practical software development techniques like those I present in class.  However, there's so much stuff that "falls between the cracks" in my approach, and my goal is that reading Pfleeger will help round out your education. Also, what I like a lot about Pfleeger is that she explicitly brings up experimental research issues in software engineering.  This is a perspective I've never seen anywhere else in a survey treatment, and why I recommend the book.  Finally, I know that some of the material was not "just-in-time", but I had to front-end load that material so that later I could assign the relevant readings. I'm hoping that this problem will not exist for the remainder of the semester. 

Review:

Review after you take a look of assignment. This could make review more efficient and pinpoint to our program problems.
  
More feedback. We put hours and hours into the projects/assignments and we learn a lot during that process. However, once the assignment is turned in the learning stops. I would like to have a more in depth review of the assignments. What was done good, what was done bad, interesting approaches, etc. I realize that is too much to ask of any Professor, so a system could be put in place such that the students review other projects and write a short report of some sort. We could also recognize projects with certain good qualities so the students can take a look at them and learn.
  
More review when the assignments are due, but I think we'll probably be doing more of this anyway now that we are starting the major (and more fun) project of the semester.

I absolutely agree that review and feedback is critical to improvement, and I will try to provide as much as possible.  One change I can make immediately is to move the software review module forward in the curriculum. That way I'll be able to implement the "system" suggested in the second comment above.  Note that once you get out of ICS 413/613, you won't have an "oracle" (me) to provide The Truth. It is critical that you learn how to read other people's code and provide helpful feedback to each other, even if you don't think you "know enough" to do it. 

Tests (or the lack thereof):

No midterm and Final. Because of my English proficiency, I would like you to evaluate us from a project and other homework, not exam. I would not be comfortable because of time limitation, but not of exam itself. I would be happy to give me more project instead of having mid and final.
  
NO TESTS! :) Maybe a few quizzes here and there, but I think that we should be graded mostly on how well we are able to develop software over time like our assignments and like how real-world projects would be instead of getting one hour and 15 minutes to see how much we can write down in that time. But I do feel the need that some individual testing is good (like quizzes) to see if everyone is all on the same page.
  
I hope there is no more exams. I have no enough time to prepare it and I don't think it's essential for us to improve our knowledge from this class.
  
Not too many written exams. Since it may not really measure the understanding of the materials.
  
My only suggestion would be to have no tests. I always freak out on tests because of the time constraints. My brain just doesn't work that fast.

This is the one place where I'm going to strongly disagree.  Objections to tests tend to be in one of two forms: (a) you don't have tests in a real job, and (b) my English isn't good, so tests don't fairly measure what I "really need to know" to be a software engineer.  In my experience, both of these objections are false. 

First, in a real job, you have "tests" all the time. They are called "meetings with your boss." In those meetings, whether you know it or not, you are being "graded" on how well you know material, how well you can present it, how well you can think on your feet, and how well you can think under pressure (assume an angry client is in the room who lost data because of a bug in code you wrote.)  Taking tests in class helps you practice all of these real world skills. 

Second, you are very naive if you think that your English speaking and writing skills won't be a MAJOR factor in the US high tech jobs you are offered, the salary you are offered, and the promotions you get (or don't get) once you are in the job.   It doesn't matter if you're the hottest Java programmer in town: if you can't communicate with others in English, and if you can't write down your brilliant ideas such that other people can understand them, then you're not going anywhere in an English-speaking culture like the US high tech industry.

Foreign students ESPECIALLY should take this opportunity, while they are in school and in an English language environment, to focus on improving their English language skills. I always cringe inside when I see two foreign students talking together in their native language in class about some technical issue. While they may believe that they are improving their productivity in the short term, they are not doing themselves any favors in the long term.  Learn how to talk about Java and software development in English before your job depends upon it!   I've written here and also here about how I believe writing a thesis should be the choice of every graduate student because of the opportunity it provides for them to address weaknesses in their professional skill set.  If you're not good at writing in English, then you should DEFINITELY do a thesis: it's the fastest and most efficient way for you to improve!

Group work and general collaboration:

I wish students were more in the habit of asking questions of each other via the class mailing list, rather than asking you directly and then having your answer posted back to the group. We're all dealing with the same issues at the same time, and frequently your answers come just after the issue has passed. (no failing, just the nature of async. communications).
  
Group work consist of more than two people. I think it would be better to make a team of maybe 4, just to make a software development team I guess.
  
More people in a group and each group takes on a little more work. Concerning the semester project, maybe three people in a group doing 2 web services or something like that.
  
It will be better if you let us keep the current group and working on the identical project till the end of this semester. Because I found the structures of every project are similar. The difference are GUI and implementation detail. Maybe we will repeat some works that we already done in current project when we move on to other projects. I would like to work on the same project so I can know the project system well.

I've tried groups of 2 through 6, and all of them have certain advantages and disadvantages. The reason I prefer groups of 2 is because it allows us to "shuffle" most easily; it maximizes the chances  that you'll have in-depth interaction with your partner; and it minimizes the chances of "freeloading" (people just "hanging on" and not contributing). 

Please feel free to send your own replies to the ICS413-l mailing list. 

Finally, rather than attempt to work "in depth" on one system for the remainder of the semester (which only gives you a couple additional weeks anyway), the better idea is to do a thesis.  Then you can really work in detail on a system for six months or a year.  That will provide you the kind of depth that you are looking for (and which I applaud). 

Additional topics

Talk about more detail about JSP tag and Java bean, and more detailed explanation on each slide.
  
I had hoped that we could have at least some discussion on EJB.
  
I wish that more in-class time had been spent on CVS -- it's an obviously complex tool, and many of us have wasted (or at least lost) hours grappling with it.
  
I wish I had a better sense of what a "good" engineering log would look like. I feel like I'm floating between diary and chalkboard in what I've written so far, and neither feels satisfying.
  
More information about the new technology that potential employers prefer.

These would all be good.  I will see if I can insert additional information.  Does anyone want to organize a 15 minute best practice lecture on any of: (a) Engineering Logs, (b) CVS, or (c) JSP tags and Java Beans?

Instructor insensitivity

There have been times when I've asked a question or seen another students ask a question in the email and your response has been something polite that translates to "Why are you wasting my time with this stupid question when you could just find the answer yourself using google?" I realize that we will indeed be better off if we can learn to get an answer from google or the newsgroups. But I think there is some sort of trade-off there, or a cost to that approach, in that now I am nervous about asking questions, and so I might not ask a question that actually would be a contribution to the class.

I hate it when this happens. I absolutely don' t want to inhibit questions, but at the same time, I feel strongly that one of the most important things I need to teach you is how to obtain answers to questions on your own.  Sometimes maybe I am trying too hard to be cute in my emails and it comes off in a way I don't intend.   I'll try harder to review my answers before posting in an attempt to avoid unwanted interpretation.  

Incidentally,  it's been a long time since there's been a question that I felt the need to redirect to google. Is that because I've succeeded in teaching you to obtain answers on your own, or simply that I've scared most of the questions away?  I hope it's not the latter.

Miscellaneous issues

The PC Lab configuration has not been updated to match your configuration requirements for ICS 413/613.
  
The system administration policies for student rights and privileges on the pc lab network are too restrictive.
  
Stimulate the incentive to learn by giving students more chances to catch up.  Give some extra bonus so that students have chance to get good grade even they did not do well in the beginning of the semester.
 

I'm actively engaged at the moment with the SysAdmins regarding the lab situation, and I'm hoping that the situation will improve. 

Finally, as for the bonus, the most important thing to do is focus on the current material, and do as good a job as you can with it, and learn it as thoroughly and as deeply as possible.  Your grade will take care of itself.