Journal Entries, Week #14

Quick jump to: alio, beowulf, jamesmcd, jkdot, jsegars, lipinski, localguy, othello, rjmorgan, ryanaip, thewang, tjice, wrprice, swong.

----- ALIO -------------------------------------------------------------------------------------------

Milestones (Completed) :

I was tasked with integrating the model attributes into the builders for people and items. This was done via the gui provided by the UI group that enabled the user to introduce demographic information into the program.

This information added attributes based off a “fuzzy logic” routine that had some predictability as far as necessary information was concerned.

Tastes based off wealth and ethnicity.
The rest were added to a person probabilistically such that people had different tastes in what they wanted.

The attributes were compared via the attribute comparator built into the api, and called via the item decide behavior.

People are also able to walk around a store of any shape because of the wander behavior. They will “wander” around and check if their path takes them out of bounds of the store. If it does then they will choose another direction and go there.

In doing this I had to work closely with TJ to get everything working well in the gui.

Other stuff:

I learned many things from this class that I realize will be very important in the future.

o A good communication structure can make the difference between a project’s success and failure.

No matter how well planned out and implemented the individual part of the project is, it doesn’t get really fun until things are integrated and break.
If you take the high level view of the project and divide it into sub-tasks then the project can proceed much more smoothly than trying to tackle the project head-on.

Listening to the other groups about their project and design decisions was educational as well. I think I learned just as much from that as I did in working on my portion. I think that is all I have to say about this semester. The overview of how behaviors and attributes work are in the model group’s documentation.

What didn’t work? Proposals for change?

----- BEOWULF -----------------------------------------------------------------------------------

Status of Milestone

Gains Made: Finalizing the remote view from the pocket PC progressed nicely. Also the documentation is now complete for the project and the demo to the customer went very well I thought. Overall I think the class was a big success. I know I definitely enjoyed the teamwork/extreme programming emphasis of this class and got a lot out of it.
Obstacles: Completing final projects for other classes competed for time, but I think we accomplished what we set out to do.
Proposed Solutions: As always, we need to set clear reasonable goals for each week, and I think we did this.

Analysis of Development

Whats Working: I think the comp sci “party” Tuesday will be an awesome way to end this class (and the semester). Unfortunately I was stupid and scheduled an exam during this time. The efforts to put together the documentation went well. Kijana did a nice job of specifying requirements from each group. Thanks to Dr. Wong also for letting us buy the pocket PC’s!
It’s not a done deal yet, but I’m working on it!
Whats Not Working: I’m not sure what we have now is ready to present at a .NET developers conference. But if some are interested in refining it I suppose it could be presented. Personally, I would be more interested in attending the conference than actually presenting anything there.
The point of the presentation at the conference is less of showing a completed, polished product, but rather to show what students can do, given the right tools and environment.
Proposed Changes: Perhaps we can assemble a small group of people willing to continue developing the product who could then present at the conference. It would certainly be a fun trip (and another thing for Microsoft to pick up the tab on)!
My dream is to somehow create a culture at Rice CS where students have projects that they work on outside of class, ala contributors to an open-source application.

Nice journal.

----- JAMESMCD ---------------------------------------------------------------------------------

Status of milestone:

Gains made: Done. Done, done, done, done, done. Documentation, done. Extraneous MallClientAdapter that would allow the client to see info about other stores, umm, sort of done. After hours of working on it and getting nothing, but extremely wired errors, we gave up at 5am. Also used the massive documenting to plan the next steps to prepare the project for the Microsoft conference.
Obstacles: Remoting giving us hell was one major obstacle. I’ve learned that the most difficult errors to debug are remoting problems. It’s never helpful that for most remoting errors you can’t actually the code where the error occurred.
The key here is testing at the proof-of-concept stage. The initial code must be slowly built up using stubs so that realistic tests can be performed on it before it is installed into the larger framework.

Solutions Proposed: No idea. Possibly have the AR people teach the other groups more about the working of remoting as they understand it. The are the most knowledgeable people on the subject, but since they can’t be everywhere, spreading their knowledge may help. A good thing to do this would be to have groups give regular presentations on the work they have been doing. Not just explaining what they did, but how they did it. Make them very technical presentations.
This is one of the issues that partner rotations in XP is supposed to address.

Analysis of Development Process:

Working: Inter-person interaction. We’ve all gotten to know each other well enough that we feel comfortable asking for what we need and questioning each others decisions, in a constructive way. I attribute this to everyone being so independently motivated and also to our various, non-class related activities, especially the water fight.
Not Working: Last minute communication issues. We’re all so busy as classes end that we forget about telling other people what we are doing and what we need. Arhhh…this bothered me a lot. Losing communications at crunch time is a really counterproductive. You can’t always count on sheer dedication on a few people to get you through.
Solutions: Make us less busy as classes end. Or have a MUCH more definite “final product” planned more ahead of time. Don’t say the final product is whatever we have done at the end of the semester. Make us have an actual goal planned earlier.

I think this Milestone was 100% completed. Additionally, I’m really looking forward to the chance to clean up this project and put together a really KICK ASS presentation for the Microsoft conference. I sure hope they invite us. They better.

Nice journal.

----- JKDOT ----------------------------------------------------------------------------------------

Milestone:

I worked on collecting, compiling, and formatting the final documentation for the project

Gains Made:

Contacted team members for various parts of documentation
Outlined structure of the document
Designed documentation and user guide

Obstacles encountered:

There was a slight communication lag - I did not get the documentation from certain group members on time (before demo). However, once the rest of the contributions come in, I will complete the documentation.

Documentation creates a cohesiveness and a overview that is crucial to actually enabling one to complete a project.

Solutions proposed:

I did post to DevHood and talk to people individually about getting the documentation to me. However, I could have followed up even more. I don’t think I talked to everyone, but I could have.

Development Process:

What seems to be working:

Documentation from the Model Group! Really clear and well structured.
Submissions on time from some group members
Will’s detailed documentation on NetHub and PocketPC. Thanks, Will.

What doesn’t seem to be working:

Still don’t have completed documentation from the AR group (I have some, but not all the details).
The UI documentation needs to be fleshed out a bit.
I still need to add screen shots and UML diagrams to make the explanations a little clearer. I also need to finish the introduction and the section on the team dynamics.

Proposal for change:

I mentioned this last time, but beginning the documentation process earlier would have helped substantially. More communication between the group and the point person for this task could have resulted in a completed document by now. It’s mostly done, but like I said, I’m missing some crucial parts.

Nice journal.

----- JSEGARS -------------------------------------------------------------------------------------

Milestone Status

Gains Made

This week was spent making the final push to get the UI completed (or as completed as we could). The major areas where the UI was lacking this going into this week were the manager wizard, the customers tab (in each UI), and the information about other stores in the manager UI. The information about other stores was dependent on code from the model group, which turned out to be very difficult (jim+symmonds@5am = it must be hard). Displaying customer attributes also never happened because of some bug in adding attributes to a person. Instead we reverted back to displaying customer names and only display the attributes if they are available. The final area of work was in the manager wizard. I spent time working with Ali to finally get the wizard and the person factory connected. More on the obstacles to this below…

Obstacles

The biggest obstacle I faced this week was trying to hook the PropertyGrid control (as seen in the Client Wizard) from manager wizard with the person. It had been a long time since I’d actually looked at this code and whatever knowledge I had of its functionality was long gone. We couldn’t figure out a clean way to make these two work together so we ended up scrapping the more extensible control, and using text boxes for each attribute. While this was not our preferred method of inputting demographics, we decided functionality was preferred over extensibility when working at the last second.

This is a sign of incomplete testing with stub code. That part of the gui only worked “in theory”, and had not actually been tested to see if it was really possible to do what you wanted to do. The code, on both sides, should have been tested up to the point where the functionality was already proven by the time the integration was done. All that should have happened was to replace the stub code with the real code.

Development Process

What's Working

As we’ve come to learn throughout the semester, communication and proximity were the keys to the development process. By working in Symmonds with the model group, we were able quickly integrate our wizard code with their builders and get an understanding of how their code worked. When I went through the code on my own, it made no sense at all, but having someone there to explain made the integration process much easier.

What's Not Working / Change

The biggest problem with the development process over the last week was the amount of time spent waiting. Most of the features that were lacking in the UI were dependent on code from other groups. While our end of the code for some of these features (such as the store watch list and information about other stores) was trivial, the code for the model was much more complex. Rather than waiting on this code to be implemented, we should have found short-term tasks to take care of, such as code-cleanup and more documentation.
How could that waiting been minimized? Once again, stub code is the answer. Instead of waiting for the model group to implement the needed functionality, that functionality should have been simulated with stub code and the UI code finished. That way, when the model group finally achieved the necessary functionality, it could be plugged right in.
Good re-tasking though to take of slack in other areas.

Nice journal.

----- LIPINSKI -------------------------------------------------------------------------------------

Milestone:

· Clean up Model Code

· Try and get MallClientAdapter up and running

Gains Made: I went through about half of the model code and made sure all of it was commented and furthermore that the commenting was up to date. On top of this, I got rid of a few deprecated methods, making sure all dependencies to them were gone. Worked with Jim in setting up MallClientAdapter to the UI. That was a headache.

Obstacles Encountered:

· Trying to understand what some of the code actually did, that wasn’t commented.
Documentation is not an “after the fact” task, but an integral part of the development process. It helps to keep one focused and helps delineate the working and understood from the non-working and misunderstood.

· Trying to figure out how exactly the mall should be represented in MallClientAdapter

Solutions Proposed: I ended up asking the other various people around, some of which had written the code, what exactly it did, and wrote comments accordingly.

Development Process for the Project

What Worked: I thought that the teams did a great job in getting things done. There was ok communication between the groups, and each group managed to get a lot done in the time we had. The stress-relief day was great, aside from the fact that Theo wasn’t there to beat on with the pool-tubes.

What Didn’t Work: Originally the plan was to develop the program using XP. While the “pair programming” seemed to linger in the form of partners for milestones the other parts of XP seemed to not be used. This includes the writing tests before writing code, switching up who’s doing what all the time, and having actual pair-programming.

We also didn’t follow the classical schema, since we did not have what exactly we were going to accomplish written down in the very beginning. Instead we tried to utilize the dynamic flexibility of XP, while programming in the more classic sense.

We also did not have a management hierarchy aside from Team Leaders. The Team Leaders themselves were great programmers etc., but they really didn’t do much management aside from actually having to write down the team’s milestones. A more aggressive role could have been very beneficial especially in team cooperation.

As pointed out by TJ, I think that there were a few people that were the “goto” people. These people ended up doing more then their fair share of the work. The Team Leaders should make sure that everyone has equal parts of the project to accomplish. Although we got a lot accomplished, and sometimes I have no idea how, it feels that without the extraordinary efforts of these people we’d still be back trying to figure out what to do. This is definitely an area where more “aggressive” role by the team leaders would have helped.

While devhood was supposed to be the main communication ground, it was utilized less and less as the semester progressed. I know that AIM was a great way to communicate with others. There was more then one occasion where Jim would be trying to find an AR member on-line to bother at 1 AM.
One has to be careful with using AIM however as there is no permanent record of the information being passed. Sometime it isn’t needed, but there are many other situations where information gets lost because it wasn’t recorded permanently.

Communication overall wasn’t great. I attribute this to people not bothering to read the stuff posted on the page, and lack of meetings between Team leaders. While class time could be utilized for communication, a lot of the time it was spent doing demos, that were remarkably slow, and trying to figure out how to accomplish this milestone. I know that the model group usually knew it’s milestones and we assigned them independently of what the other groups were doing.

I won’t even start ranting about SourceSafe except that until a version that works is released, use something else.

For Next Year: Rethink project organization. The hybrid of XP and classical programming didn’t work too great, and using a solid version of either might be a better approach.

Shortly after the project is revealed have the students submit what they think they can have done by the end of the semester, and possibly include that in the Journal, so that there is always a final goal to shoot for. Note that this is the customer’s specifications essentially. Did people do an effective job of articulation those specs?

If there are teams again, then make sure the team leaders are more active, in defining the project and coming together to develop the milestones for their groups together. That way all the groups know what the others are doing. This almost suggests the need for a top level management, one person to control everything and assign the different groups what to do. That, or a team leader meeting, would have been ideal for making sure all groups know what the others were doing.

Moving Exciton to Symonds might be beneficial if SourceSafe is going to be used from Exciton. After switching to Ryan’s computer, developing was a lot easier. Having to wait an hour to get the latest version, put a damper on project development.

Possibly have everyone have a way of instantaneously communicating with each other, either through MSN Messenger or AIM. That would mean giving everyone in class a list of the other’s MSN or AIM name etc, or putting it on the web with e-mail etc.

I’m not sure what to do about uneven work loads, but that is a problem to be solved.

Nice journal.

----- LOCALGUY ---------------------------------------------------------------------------------

Milestone:

Gains Made:

I went through all of our code and made sure our comments were descriptive and I added commenting where it was needed.
I double checked some of our closing code and fixed a small error.
I wrote the documentation that Will assigned me for the week and sent it to Kijana.

Obstacles Encountered:

None really, it was nice that the customer seemed satisfied.

Solutions Proposed:

We’re done!

Development Process:

What seems to be working?

Everything is finalized the project was a success!

What seems to not be working?

I would like to see a public web page for the project so that we can show it off to people. When the project is absolutely done it would be cool to put up some binaries and all of our documentation. I really want to put everything on a CD that I could give to people at job interviews.
I posted the docs and code. But I agree that a nicer “presentation page” would be better.

Proposals for change:

I would like to see our project shown at the .NET convention in Dallas, but I will not be around since I’ll be in Seattle. I think we should keep everyone on the listserv updated about how things are going. I would be willing to help organize any kind of presentation if people are willing to work on it.
Great. Your help will be needed.

Nice journal.

----- OTHELLO -----------------------------------------------------------------------------------

· Milestone Status:

o Gains: I finished my portion of the AR group documentation for the project – that was my only assigned tasking during this last period. It encompassed feature outlines, design process, and code decisions made by the AR group. I sent it to Kijana, who compiled the class-wide manual.
Other groups, particularly the Model group, but also the UI group, were short-handed. Re-allocation of human resources was needed to prevent the project from depending on “heros”.

o Obstacles: Last week of classes is very difficult in general, especially for Comp majors, as few things are due during finals. Most courses just push everything to the last week of classes to allow time for grading.

o Proposed solution: Thankfully, we were allowed to submit this after class ended, and we had a chance to recuperate.
This is not a proposed solution. What could be done in general to alleviate such “crunch times”?

· Development Process:

o What’s working: Lower load on the last week of class.

o What’s not working: Can’t think of anything at the moment – which is funny for someone like me. I think we’re bearing on each other some, after a lot of exposure over time.

o Proposals for change: Irrelevant since the process is now over, (not irrelevant at all, considering that good person—person interactions is crucial to project success. Think about what can be done to help maintain healthy personnel relations in general) but about the bearing on each other, it’ll be nice to have some time apart :-P, although like Kijana, I might miss some of the guys now that I’m graduating :-D
--Actually, its that we’ll all miss Kijana. L

· ----- RJMORGAN --------------------------------------------------------------------------------
Status of the student's milestones (75%)

o Gains made

My major tasking for this milestone was to write a User’s Guide to the NetHub executable. This guide explains how to use the NetHub and supporting libraries in a step-by-step fashion, and Kijana will be including this in the documentation. My other tasking was to oversee the testing of our application to ensure that most of the bugs were either known or fixed.

o Obstacles encountered

I had originally suggested the test team idea when I thought that the goal of the class was to produce a stable, “shipping” product for the customer. Over the course of the week I found that numerous changes were still being made to the application, and that the production code was far from stable. Testing an application at such a stage would have resulted in me producing an ever-changing list of bugs, many of which might be irrelevant as the code continued to change.
But does that negate the need to do the testing? Testing and development are not separate processes. They are intimately linked and feed off of each other.

o Solutions proposed

Once the application is deemed relatively stable, a test team should dive into the problem of locating all the minor bugs, while the code is frozen. This team will come up with a concrete list of bugs for that point in time, and after the code freeze, developers can go back into the code and make fixes.
It sounds like regular code freezes for the sake of testing is a good thing.

· Analysis of development process

o What seems to be working

This class has done an exceptional job in working together and in dividing the labor between people with very different skill sets. Everyone stepped up in the area they knew best – Kijanan: UI, TJ: graphics, Theo: OO design, etc. – and it made a tremendous impact on the development and quality of our application. I’m very pleased with the way our application has turned out.

o What seems to not be working

Since we were forced to focus so much of our effort on PocketPC development at so late in the game, completing the Windows application and getting it to a stable release somehow fell through the cracks. In an earlier journal before PPC development began, I addressed this point and I’m really upset that we were unable to focus our efforts on putting out a quality product with lots of cool, working features. I think its really disappointing that Dr. Nguyen is not able to design his own mall layout, since that is one of the main things he wanted to do.
Advance preparation for unknown technologies, such as the PPC was, is crucial for overall success..
Perhaps the most serious issue is not meeting the customer desires in general. Such omissions could cost a company an entire contract.

o Proposals for change

Next year I really think there needs to be someone in charge of quality assurance as soon as the application parts get integrated. This would go a long way to ensure that the results of our class are productive and stable.

Nice journal.

----- RYANAIP ------------------------------------------------------------------------------------

Development Status

Our code was in pretty good shape last week – most of the functionality was there and it was getting more robust. This week was spent cleaning up the code and working out small bugs, as well as writing documentation (thank you Kijana!).

Jim, Bryan and I also spent most of a night working on implementing the MallClientAdapter, which would allow the stores to get information about each other. We have code in place that we think should work, but there appear to be subtleties in remoting that are causing problems. If we choose, we can spend more time on it and get it working. (But it was on our list of “if there’s time” pieces of code, so it may be more worthwhile to clean up the things that are already working.)

On the whole, I’m very satisfied with how far we got on the project over the semester. Like Dr. Nguyen said, it would be nice to have more specialized people – bouncers in clubs, waiters in restaurants, etc. I think, however, that our system is designed well enough that something like that would be easy to put in. We’d just have to add an interface to design the people and write some code to load in external libraries containing their behaviors. So the hard part is all done. (I also think that Dr. Nguyen may have underestimated the amount of work that went in to remoting and networking – The things that should be easy but aren’t because they’re so new.) Note: is it the customer’s responsibility to estimate how much time is required to implement a particular technology?

I’m confident that we can put together a streamlined and stable application for the conference in June if the opportunity to go works out.

Process Analysis

The class has clearly grown and learned a lot about how to work together over the course of the semester. Everyone took ownership of the project and figured out how to best use individual people’s strengths. Once that happened, we started working very effectively. (And some people who hadn’t been as involved earlier in the semester really stepped up at the end.)

One of the biggest hurdles we had to get over was figuring out a balance between over and under-specifying our taskings. Since we’re not a full-fledged, 5 days a week organization, we’re much less connected on a daily basis, even now that communications is strong. That means that people had to have room to independently change what they were working on as the jobs became clearer and schedules shifted – The decisions couldn’t wait until other people were around to approve. On the other end, under-specifying taskings made it difficult for people to decide where to go at all. I think that by the end of the semester, we found a balance that was working well – a good adaptation of the XP design methodology for an academic environment. (The three group thing helped, too.)

Next year, it might be a good idea to put a code-freeze during the last week. (Or just a code-chill, so people could still fix bugs.) That would leave more time to put together documentation and a presentation, which seems to be something that Dr. Nguyen expected more of than we had together.

Nice journal.

----- THEWANG ----------------------------------------------------------------------------------

Milestone Status:

Gains Made:

· There wasn’t a particular milestone for me and Ali, just that we had to get the attributes and behaviors integrated with the UI and factories. However, it has been integrated, the items are able to have attributes, the people have attributes based on demographic information, and they are all comparable.

· We discussed the project with the client and got his input and reactions to the work that we did.

· The project is done. Or at least done enough…

Obstacles Encountered:

· Apparently the demographic statistic collection class doesn’t work exactly as it should. If we get to present this will definitely be fixed. I don’t know if it is linked from the GUI yet though.
Lack of good stub code testing again!!

· What we decided was a good enough challenge, a good enough project, wasn’t what Dr. Nguyen thought was good enough. (see next section)

· Not really having a milestone set out, and kind of “sharing” a milestone with Ali is hard for getting together.
Good tasking is crucial in the end game.

Solutions Proposed:

· Get the demographics working and integrated with the GUI.

· Write more (some) unit tests. Should this have been an after-the-fact solution?

Development Process:

What Worked:

· I guess this will be the development process over the whole semester:

· Pair programming definitely worked. Coding parties were good too because we could just yell and say what we needed from others.

· Inter-group communication (later in the project).

What Didn’t:

· Lack of milestones. Definitely a killer.

· Lack of overall vision on the project. It would be nice for someone to have monthly milestones set. Like TJ (I think) was saying in class, it would have been good to have one person managing all of the groups or group leaders.
Here’s a question: Did anyone ever really write down a good description of what the customer wanted in the first place?

Solutions Proposed:

· Perhaps the deadline could be a week before the last week. Then we could collectively get together and decide what more needs to happen to make it work robustly or needs to be added to make it appealing to the customer. Dr. Nguyen didn’t seem to care too much about the net hub stuff, and was more concerned with what he could see.
Sad fact is, most customers will only care about what they can see, not what is under the hood.

· Spend the class money on a faster server instead of PocketPCs. I really barely even touched mine.
It’s not clear that the speed issue is the server itself, but rather the network connection between Symonds and Exciton for the most part.

Nice journal.

----- TJICE -----------------------------------------------------------------------------------------

· Milestone Status:

Gains: I have added holes to the layout and I have also tweaked a few problems that occurred in the rendering of the simulation ( i.e. when people went through doors there was a jumping effect. ) I also fixed the Pocket PC GUI. It now works on any machine – not just 128.42.46.62. J

o Obstacles: There were only coding issues, and time issues. I could not get everything I wanted done on this project done. I think the AI for people could have been tweaked, and configuration files for stores and malls needed to be made ( i.e. stores aren’t interesting right now, and maybe we can incorporate different images for different items – this would be a plus to actually figure out what the heck is going on. )
Perhaps a more serious issue is whether or not the capabilities of the system have been properly tested given the limited number of things going on in it at the moment.

o Proposed solution: We have a few weeks before the Microsoft Conference; let’s hammer it out.

· Development Process:

o What’s working: Communication is good. This has been a pretty good class. The amount of work that was accomplished is impressive, now looking back on it. I would like to thank everyone for their individual work. I wouldn’t mind working with you guys again ( even Jim. )

o What’s not working: It’s the end of the semester. I have to say everything is working. Nothing is ever perfect, but we some manage to communicate and solve problems without killing each other. This is a plus.

o Proposals for change: I propose that for next semester, just make sure that whoever is in the class really doesn’t mind learning things on their own. And try to add a small group to actually make sure all of the sub-units are working in order. I felt that the first 8 weeks in this class were counter-productive, because different groups were not on the same page.
A testing group would definitely be a beneficial thing for a large, complex system such as this.
As far as the first few weeks is concerned, would you have really learned the lessons about communications, tasking, etc, if you hadn’t gone through those rough first weeks?

Nice journal.

----- WRPRICE ------------------------------------------------------------------------------------

Gains Made:

Submitted final high-level documentation for the NetHub, its libraries, and the rationale behind the PPC web service and client classes.

Obstacles Encountered:

None – just had to force myself to sit down and update the previous documentation and write about the new stuff from scratch.

Solutions Proposed:

Duplicate and bind all submitted documentation at Kinko's, distribute to class.

Development Process:

What's working:

Everyone was tasked this week, regarding documentation. Also, despite all my doubts, the PPC implementation finally came together by the end of class; that's amazing, given our (lack of) experience and time frame.
Unfortunately, it took some heroic efforts on a few people to accomplish this. On the other hand, it is a testament to the quality of the system design that the addition of the PPC was relatively painless.

It seemed that some people were undertasked at the end, partially because it wasn’t clear exactly what needed to be done to get the project finished.

What's NOT working:

We're not in class anymore, so the project is in its “final form,” like it or not. It's a shame that it will basically die after this... then again, I don't think I'd want to work on the same project for another semester (at least not as a part of the AR group).

Proposed Solutions:

Everyone gets a good grade and goes home happy for the summer. :-)

Nice journal.

----- SWONG ---------------------------------------------------------------------------------------

One of the major issues that came back to bite people was the lack of good stub coding for testing. This meant that certain sections were not fully tested and the ensuing problems came up when the teams could least spend the time on such distractions. Remember, the stub code is not the part of the code that attaches your section to the API, but rather the stub code should be simulating the back end of the API, so that your code is 100% complete and 100% testable.

The lack of a comprehensive description of what needed to be done to finish the project was a crippling omission. Creating documentation is part and parcel of the development process because it creates that complete view of the system that is needed to figure out what to do next. This lack of a complete overview also affected the presentation to the customer, creating a haphazard discussion of the features and capabilities. A much better job will be needed to present the work to Microsoft and other educators.

But, all in all, I must say that I am very proud of all of you. You put in a tremendous amount of work for this class and have come a long way since the beginning of the semester. I feel we all learned a lot from the experience. You have achieved more than most undergraduate CS students could even conceive. Do work on your ability to articulate what you have accomplished as this will serve you well in job interviews and other such situations. I would recommend having a demo ready to run at a moment’s notice as there is nothing like the real thing to make an impression.

I had a wonderful semester with you all.

GREAT JOB!!!