I can be nice when you play with me

I really like the way you all decided to work during the lab time today. I can't help but think that many of you wouldn't be so far behind if you had been that aggressive a month ago. However, I am so pleased by today that I'm giving a small gift. Instead of everything being do by Thursday's class, I'll give you until Friday at midnight!

Good luck and keep asking questions!

What a State of Affairs!

Again, you all played nicely with state machines today. They are a significantly different strategy for designing a system and take some getting used to. Thanks for sticking with the details and not getting too frustrated.

I really wish the book's example was more consistent because state machines can be a very disciplined way to specify the behavior of many kinds of systems. As with all techniques, when we build the machine inconsistently, the resulting code also has inconsistencies. If you're going to use them, just be consistent about what is an input, what is an action, and whether you're building a Mealy or a Moore machine.

I was also pleased with how quickly you saw two important concepts: the tight coupling in the book's solution and how our solution exactly matches the strategy pattern. You all are getting VERY good at this. I see some significant improvement in your ability to evaluate designs and make good generalizations and that makes me very happy!

Today was fun!

I really enjoyed working with all of you running through the GA today. Maybe we should have done all of that the first day that we talked about the project. Or maybe it was good that you thought about it a bit first (I'm an optimist - I believe you have all been thinking about the stuff that you're supposed to be working on! ).

Any way, thanks for playing with me. I hope that it cleared up some of the details for you.

I'm all better now

I'm quite relieved since we eliminated the deadlines. I was laying awake at night trying to figure out how to make you get started. Now that I've decided that's really your responsibility (which it probably was all along :) ), I'm feeling much better.

I have almost completed the changes to breakout and I think you'll find that to be an interesting project. As I said in class, don't bring all of the tests into your project at once - that'll overwhelm you pretty quickly. I'll try to come up with a recommendation on what order to start them in to help with that.

As always, if you have questions or are having difficulty with something (like figuring out how to start the paper), ASK ME FOR HELP! That way we'll all sleep better.

Spring Break?

I have to admit that I'm sitting at home during Spring Break worried about the work you all have to do. No one has given me a draft of a factory pattern paper to review, so I can only assume that you all are working on them during your break. Also, we have a lab that is supposed to be done the first week we get back.

I'm not sure if there is something I should do about this or any way I can help, but I am concerned. Should I delay one of the deadlines? I could do that, but I think we need to continue to make progress, too. Would that just let you pile things up to a later date or would it help you do a better job?

I could use some suggestions!

Command Pattern

First, the test. I was pleased with how you did. While the averages on my tests are usually lower, I think I asked the questions that mattered and you all just did well. That's a good thing! I was only kidding about making things trickier!

Second, the class. Things seemed Ok to me today. I think the command pattern is pretty straight forward and the example in the book is better than most because it seems more realistic. Most of you seemed to be with me; we'll see if that's true when you work on the lab.

Third, the paper. I would like to see your drafts before break, but I do have email over break and will give at least some feedback whenever you give it to me. I just don't promise to be as available over break as I usually am! I still think you've never written a paper like this, so expecting to do it well without any feedback is naive. I'd really prefer to help you than to have to grade incomplete papers.

Singleton

Boy, the Singleton lecture was fun! You all did a great job with the dining philosophers game. It's interesting to me how many different variations of solutions students come up with for that problem. For this class, the details of that problem are irrelevant; my goal in playing the game was for you to see the devious scheduler and I think we achieved that goal very well.

When we went into the various options for Singleton implementations, more of you were participating than ever before and, more than any class I've ever had, you seemed able to spot the places where the devious scheduler could rear it's ugly head. In previous classes, the double checked locking examples have always confused everyone and making them see why you need two conditionals was a terrific challenge. This time, you were right with me!

At this point, I'd say at least three quarters of you are actively participating in class and are really thinking about what we're doing and where we're going. That's a HUGE improvement from where we started the year and I'm really impressed with you. With those skills, we'll have some fascinating discussions as we get into the more complex patterns.

Obviously, I think Singleton went well. However, if you have questions, please ask them. We aren't going to do a Singleton lab (we have an exam and it'd be pretty trivial), but I think you'll see one in our big project.

If you have questions about the exam, I'll be on line most of tonight and I'll be in my office early (7ish) tomorrow morning!

Factories

I liked both of our factories days (the lecture and the "lab"). We are beginning to get to the point where we can talk about more details than just the structure of the pattern. Good software developers know the patterns; great ones know when to apply them.

In the lecture, walking through the code instead of having me present it modeled an important skill: learning to read someone else's code. I wasn't kidding when I said that one of the first things you'll have to do on the job is make sense of someone else's code. Strategies for making sense of code that is made of many classes are useful things to know.

However, I also liked the discussions that we had about the pros and cons of each of the factory patterns. Those are the things that development teams debate when they are selecting a design and learning to weigh those considerations is an important goal for this class. We carried that much further when we talked about the paper. I know you all hate papers, but I think that it'll give you an experience that will be valuable when you graduate.

I'd like to offer some sage advice: when your management (or faculty member) offers to review something before it's due date, you should take advantage of that mentoring opportunity. This paper is very different from anything you've had to do in the past and it counts for a good portion of your grade (it is one of two projects), so getting advice for a more senior member of the team doesn't show weakness - it shows wisdom.

Decorator Lab

I was pleased with today's lab! Some of you asked very good and insightful questions which made me very happy! I don't know why, but Decorator seems easier than Observer for students every semester. I'm glad we've hit on something that seems to be going better; maybe we're over the hump . . .

Decorator Lecture

I certainly had fun in class today. As always, I hoped for more questions, but maybe it's OK. At least you're talking to me now. :)

With today's lecture, I was trying to show you real code for a bunch of examples because the decorator is easy to see, but the details can be strange to follow. You really have to be disciplined about delegating to the inner object because you can't depend on the order in which the decorators will be applied (in other words, no decorator should make assumptions about which things it wraps).

My mom suggested that I force you to talk more during class by making you repeat what I just said. I really don't want to do that because I want you to learn how to ask questions. As an alternative, let me give you a suggestion: any time I say something, you should be asking yourself, "Why is it that way? Could it be any other way? If something changed, how would that affect the pattern?" For example, when I say all of the decorators have to be subclasses of an abstract decorator class, you should be thinking, "Why is the decorator an abstract class? Could it be an interface? What would happen if I had two different categories of decorators? etc." Always be trying to figure out the motivations for and the limits of each pattern we discuss. Maybe that will generate some questions next time!

Observer Lab

Today's lab met my expectations, and I think I need to re-make my point about efficiently using your time.

I have no doubt that, if you bang your head against it enough, every one of you could figure out how to build this code on your own. However, most of you barely got through making PriceHistory observable (any many of you didn't even get that far) before class was over. This means that you've spent a lot of time on material that isn't central to the topic we're studying. There are a limited number of hours in a day and you have more classes than just mine, so I have trouble believing that you have time to bang your head long enough to do this on your own. It's a question of using your time efficiently.

When you leave school and get a job, they are going to want you to be an independent problem solver. However, they are also going to want you to be able to recognize when you are wasting their money by banging your head over a problem. You will be part of team that is depending on you to get things done efficiently. The abilities of knowing when you're stuck and knowing how to ask insightful questions that are targeted on getting the job done are part of being a strong developer.

I really do want to help and I enjoy answering your questions, so please try to use the resources around you more efficiently!

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.