Skip to main content
Spring 2005

Spring 2005

Search
Spring 2005
Home
Customer Resources
Document discussion
Model Team Website
Network Subsite
Team Leader Website
Visualization Team
  
Spring 2005 > 02/04 Journal  

02/04 Journal

   
View: 

1. Name

 Michael Friedman
 (100%)  

Total: 1

2. Milestone Status: Gains made (If possible, include hyperlinks to what you mention here.)

 
We worked on UML diagrams and design notes for the Pocket PC client. These are available in the shared documents folder. They are ready to be shown to the client, if that is desired.
 (100%)  

Total: 1

3. Milestone Status: Obstacles Encountered

 
As noted in the milestone report, our original milestone was somewhat ambitious. We scaled back to just coming up with a design instead of an actual implementation. The hardest decisions were what behaviors the Pocket PC should support. We talked to Travis McPhail about the limitations of the PPC. This helped us write what we hope will be appropriate interfaces for adaptors.

I unpacked and charged my Pocket PC, but I haven't had a chance to sit down with it for a few hours and get it all set up and whatnot.
What were the specific obstacles that required scaling back this obstacle? What parts did you choose to leave to a later date, and why? Are the limitations you've encountered documented anywhere in an easy-to-find format (i.e. not buried within a document of larger scope)? — Will Price
 (100%)  

Total: 1

4. Milestone Status: Proposed Solutions

 
See the design documents.
 
What do you propose to do to help you create more appropriate milestones in the future? This can be a hard question.
Which obstacle above does the design documents solve, and how is it a solution? (Maybe I'm missing something.) The document seems to raise more possible obstacles than it seems to solve; for instance: who's writing the IViewEventAdaptor implementation for the PPC (you or the model team)? How will the IViewEventAdaptor implementation literally connect to the server model (Web services? Raw sockets?) and what are your options on the .NET Compact Framework? Have you researched all your limitations (not just graphical or memory ones)? — Will Price
 (100%)  

Total: 1

5. Development Process: What seems to be working and why?

 
I enjoy working in a smaller team. It is much easier to communicate. I don't know how the Model team is doing, but I'm glad I don't have to coordinate with that many other people. When you say you don't know what the Model team is doing, do you mean that you do not know how they coordinate so many people or that you do not know what projects they are currently pursuing? The latter is a problem because it means you do not know, for example, when you can expect them to write code to go with the interfaces you designed.
 (100%)  

Total: 1

6. Development Process:  What does not seem to be working and why?

 
We've had some trouble getting started with Flywheel and Vault. The license file for Flywheel didn't work on the computer I tried it on in Symmonds. It works on Loughry's laptop, which is good enough for now. Similarly, Loughry said he has had problems with the Vault software. Hopefully, we will figure everything out with more practice and experience.
Be sure that other people know that you are having these problems in Flywheel and Vault.   They can either help you because they've already solved them or they can be saved a lot of work because they know that there is a problem and perhaps what your solution is.  -- SW
 (100%)  

Total: 1

7. Development Process: Proposals for change--issues addressed and why the change will help.

 
Hopefully things will pick up once we have some code from the Network and Model people to interface with. Until then, we can work on the PPC client. One thing that worked well for us was to include dependencies as part of our milestones so that everyone knew what we were waiting on.
Speaking of dependencies... do the Model and Network teams know what you need from them, and how soon they need to get it to you (so you aren't sitting on your hands). Along similar lines, if it turns out they can't get you what you need for a while... do you have any backup plans for what you can work on next? — Will Price
 (100%)  

Total: 1

8. Additional Comments

 
I'm not entirely sure why we are having an XP debate. It seems like a waste of time that could be spent working on the project. I personally don't like XP because of the whole pair programming thing. Pair programming might be a good idea for people who are always in the same office all day, but for students, its horrible. When I am required to pair program, finding times to meet with my partner always gets in the way of actually getting work done.
Not all parts of XP are applicable to every solution; however, just because you may not like one part doesn't mean you have to throw the rest away. There's more to XP than simply pair-programming, and XP is intended to help write better code. The debate will hopefully show what XP practicies you can salvage and leverage to good use in the remainder of the semester. — Will Price
Always remember that this is a software engineering course, not just a programming exercise.   The point of the debate is for you to spend some time thinking and articulating the various aspects of different styles of development.   Thus, if you ever find yourself in a job where they go full tilt with XP, you'll know what pitfalls to avoid.   Likewise, if you find yourself in a non-XP situation, you'll know what notions you can import to make their process better.  -- SW 
 (100%)  

Total: 1