Observer Lecture

I could summarize today's lecture with one word: fast! I thought that it'd take longer when I prepared it. I hope that you all were with me the whole way and that you'd stop me if you weren't.

I REALLY liked the discussions we had about alternative designs. There are always many ways to approach a problem. Learning to visualize those alternatives and weigh their costs and benefits is a skill that distinguishes average engineers from great engineers, so I'm happy to have those discussions. When we take those side routes, do your best to stay with us and keep asking questions of me and your colleagues until you see the alternatives and the issues we are weighing.

One other comment about weighing choices. There is rarely a choice that is best in all situations, so the debate is normal. When your colleagues (or your professor) take the opposing position to yours, it doesn't mean you're wrong - it means we are looking at all of the alternatives. As the semester progresses, I expect many of you will have alternatives you'd like us to explore. Do that with an open mind and don't get defensive when the discussion heats up. In real life, those design debates are critical the resulting quality of the system. The more eyes on the issues, the better the result will be.

Similarly, I've had a number of people ask: why don't we do this with a different language or with a different tool set. The principles we are studying hold for all object oriented (and most top down) design situations. We're using Java and Eclipse because they are tools I'm sure you all know so we can focus on design, not syntax details. I have never said that Java is the best language for all situations and, in fact, I choose to use other languages for some situations. There is no "best" language; focus on the principles and use them with whatever language you choose.

Strategy lab

I think this lab went a bit better than our first one. You did ask a few questions which gave me a purpose! :) I'm sorry that my instructions led a couple of you astray, but I think we got those issues ironed out.

I am a little concerned that no one finished the lab. Obviously, as you get further into it, things become more complex and I'm sorry that you didn't get to those parts before class was over. Be sure to continue to ask me questions (email, IM (drwellington), in my office, etc.) as you are finishing the lab.

The lack of questions in the first half hour of the lab gave me an idea and I'm interested in your feedback before I pursue it. We could talk about the lab at the end of the lecture on Tuesday and I could give you the setup instructions then. That way, you could have the lab set up before you come to class on Thursday. This would improve the odds that you could get to the meat of the lab during class on Thursday. Let me know what you think!

Strategy Pattern Lecture

I think today's class went pretty well. Here are the things I liked:

• you started asking and answering questions,
  
• we looked at two examples of code that used the pattern, and
  
• we did some brainstorming on how to apply the pattern.
  

I'm hoping that you all followed the duck example and why our early design strategies wouldn't scale nicely, but I wish I would have focused on the concepts of scalability and adaptability more. One of the original motivations for many of the design patterns is that our customers' needs change with great regularity. This means that our success depends on our ability to modify our software easily without introducing defects. We'll get to talk about this some more, but I wish we would have started that conversation today.

When I think about the time we spent writing the bank account example, I'm afraid it went too quickly. There were a lot of details and I'm not sure how much you can watch what I'm doing in Eclipse. When I write code in Eclipse, can you see the code? Can you tell what I'm doing with things like quick fix?

BTW, the podcast for the programming part of the day got corrupted some how, so I re-created it. I tried to develop the code in the same order we did in class, but I had some extra details to talk about the second time through. You might want to watch!

Finally, I'm afraid that many of you didn't follow the mock object stuff in the tests we built, but I'm not too worried about it. You'll do it again in the lab on Thursday, so we'll have another pass at it. However, in general, we need to find a way to make sure that you can pick those things up in class. I like coding together, but any ideas on how to improve these parts of the lecture would be appreciated.

First Lab

I really liked this lab when I created it. Last semester we dove right into the patterns and it seemed that the students were missing experience with a number of the topics we talked about in the introduction. I'm hoping this lab will cover that gap. Also, I think TDD will be very helpful as our labs become more complex, so I'm glad we had a chance to practice it before we get involved in new material.

I think, in general, you made solid progress on the labs and I'm pretty confident that most of you will be able to finish it by Tuesday without any trouble. As a class, you all seem much more comfortable than my previous classes with the OO concepts we'll need.

However, I have some concerns about how the lab went. First, you all chose not to work in pairs even though I nagged you about it. It's important that you understand that I don't ask you to do things for the shear joy of watching you suffer! I know that working in pairs can be awkward, but it was important to this particlar lab. I asked you to work in pairs because I was asking you to do something in a very different way than you have used in the past. When you work with someone else, you have the opportunity to reflect on how a technique is working because your approach will differ from theirs (even with the specific instructions I gave in the lab). While that reflection is valuable, sharing it amongst yourselves lets you also see how the other person is analyzing the technique and can give you both new insights. In general, when I ask you do something, I have a reason why it's important, so you should try to follow it.

My other concern about this lab is that very few of you asked any questions. In some ways, that underscores your technical knowledge, so maybe I shouldn't be worried. After all, you do seem to be able to finish the lab. My concern is about the level of understanding you got out of the lab. The instructions led you through the mechanics of TDD pretty thoroughly, but I was hoping you would have questions about why you were doing it. TDD is very different from the ways you have written code in the past and understanding its motivation is an important part of really understanding TDD. And that's true with everything in life! Particularly in educational situations, you'll understand what you're doing better if you reflect on the motivations behind what you're doing. As an engineer, you should always be thinking "Why am I doing this?" and "Is there a better way to do this?" In my classes, the more questions you ask, the better you will do.