Journal Entries, Week #9

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

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

Status:

Code review is completed and posted.
This code review helped in several ways because we get to see what is going on with the other groups more than we would if we were concerned with achieving milestones for our assigned groups. Also this stresses the importance of straight-forward code, important for extending and comprehension for people not intimate with that part of the project.
The only thing that took some time was to understand what was going on in the code I was reviewing. But, thanks to good commenting and structure this was a small problem.

Looking Forward:

Now that the reviews are in and we are going to be assigning tasks and making a better product we should be thinking about testing scenarios. The project is at the point where it could take off and become more complex than it is right now, and good testing is essential. I know personally I have been lax about my unit tests but I think this should be an important factor in the next milestone.
Also when is the code freeze officially finished?

The code freeze is off now.

How would you improve the code review process?

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

Status of Milestone

Gains Made: This was a slow week in terms of development, and it took everyone a little while to get back into the swing of things, but when we finally got into doing the code review it was worthwhile. This will be a big step toward group ownership of the code, which is a very cool part of extreme programming. Also, the documentation we all added by Tuesday made the code review easier. I’m looking forward to the guest lecture next Wednesday.
Obstacles: It being willy week, everyone was running around doing jacks and filling balloons rather than working. Attendance might be a little light again at lab. We had problems finding other groups documentation. We should have agreed on a consistent place we would all put our documentation for this review.
Proposed Solutions: Hopefully we’ll get settled back into our routine in the next week. And we can all choose a folder next time.

Analysis of Development

Whats Working: I’ve mentioned it before in the past, but when we all get together in symonds (like to do code reviews) we are productive together. And its fun to watch Will and Jim fight.
Whats Not Working: Exciton is still slow when 7 people work on it simultaneously! Also, we need to make it a priority to get stuff working on our pocket PCs soon, because this will justify buying them and we might get to keep them cheap! Same for tablet PCs J Its also interesting to see more and more bugs cropping up in VS.net and sourcesafe.
Proposed Changes: It would be awesome if we could get VS.net going on the individual machines in symonds. Some more patches will come out I assume as vs.net and sourcesafe mature a little bit.

Nice journal.

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

Status of Milestone:

Gains made: I now have a “full” understanding of what the AR group’s new NetworkingHubLib does and have formed many new ideas on how to re-implement a more final version of how connections will work between spaces.
Obstacles Encountered: The biggest problem with reviewing someone else’s code is just not having any idea what is going on in the first place. There is a major learning curve associated to reviewing code in just understanding what is going on. It takes a very long time to learn this information before you can actually get on to making helpful suggestions about a groups code.
Solutions: Assign one person from each group to coach the people reviewing their code. This person’s review will can simply be of their own code or you could still assign them to review another groups. This helps alleviate the problem of being bogged down and distracted by low-level code before you can look at the bigger picture.
Good suggestion.

Analysis of Development Process:

What’s working: This milestone has given us the chance to get to know a different branch of the project better. This should hopefully help solve some arguments in the future that arise from a lack of knowledge of the project.
What’s not: I feel this week might have been better spent reviewing our own code. I know that takes away one of the major aspects of doing the code review, but I feel many of the suggestions, though valid and helpful, will not be as useful as ideas we could have come up with on our own, at least at a high level design standpoint. At least in our group there have been a lot of things we have been looking forward to reworking and an extra week would have given us the chance to do this.
Ahh, but shouldn’t you be doing this anyway, every week? The point of the code review is to get some fresh eyes on the code.
Solutions proposed: Perhaps the next code review should just be a week long and involve having the group set their tasking based on an explicit list of things in their code that they would like to rework/rearchitech/redo.
You should always be doing this, I think.

Nice journal.

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

Milestone:

I put in time last week and at the start of this week working on documentation of the MallManager GUI code. This consisted of in-line commenting. I’ve also been thinking ahead a little to the next round of user testing (on the functional version of the code). I also met with Brain to work on my code review for the Model group code.

Gains Made:

Gains included completing documentation of GUI code and working on a code review of the ModelCode.

Obstacles encountered:

Personal scheduling issues this week prevented me from starting my code review earlier. Also, there was certain vagueness in the review guidelines. However, I got it figured out after talking to the model group. I also realized that I don’t have as good a working knowledge of other people’s code as I should. I just assume it works and don’t really think of looking at it to improve it. I guess this is the point of this exercise. Exactly.

Solutions proposed:

I could be a little more involved in code discussions (instead of staying in my own little world. I guess I’ve distanced myself a bit because I was focusing on a particular part of the application (and not worrying about the guts). I need to worry about guts.

Development Process:

What seems to be working:

Relationship between the Model and UI groups
Willingness of other people to explain their code and thought process. This was particularly helpful when I was looking at foreign code for the code review.
The lovely weather.

What doesn’t seem to be working:

I think we may be a little lost as to what will happen next. While we are still trying to patch things together, we should concentrate on a fully functional application (it’s getting there!). Personally, I know that in the UI, we have a good amount of work to do with making proposed features a reality (watch list, chat, etc.). Now that we have something working, we have a better idea of what will actually be possible to accomplish.

Proposal for change:

Concentrate on the basics of what we promised to deliver and then work to add the other features. There still seem to be a lot of bugs in the system, but I think they’re getting worked out. Some weird and mysterious errors could be tasked to a couple of people for problem solving…I don’t know if this would expedite matters, though.

Nice journal.

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

Milestone: Code Review

Gains Made

Gains made this week in the code review were two-fold. First, going back through old UI code to make sure that it was fully documented made us think about some approaches we’d taken initially and kept us aware of areas where we’d only hacked code to make it work for a certain case. These hacks need to be cleaned up in the next milestone before we move on to adding new functionality and forget about them.

Gains were also made in general understanding of how the whole project fits together. I obviously had a good grasp on the UI code, and a decent understanding of what was going on with the model, but I really had no idea what AR was doing. Reviewing their code gave me a better idea of how it all fits together.

Obstacles

The biggest obstacle in the code review was my lack of knowledge of AR code. This was the first exposure I’d had to their portion of the project or remoting in general so it took me a while to figure out what was going on. The high-level documentation they provided, however, was very helpful in gaining a general understanding of how the NetHub worked.

Development Process

What's Working

I didn’t actually do any new coding or work within the UI group so if there’s any part of the development that is (or isn’t working), its related to the code review. I do think the code review has been very helpful in allowing everyone to slow down from the “I have to get this done for a milestone” mentality and think about why we’re doing things they way we are.

What's Not Working / Change

As I stated above, I haven’t done any coding or other work within the UI group this week. Combining this with spring break last week, its been quite a while since we’ve really worked within the group or made progress on the UI. Hopefully, things will be fine when we start working next week but I’m not positive that we’re all on the same page still.

Nice journal.

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

Milestone:

· Review UI groups code. (%100)

Gains Made: I was able to suggest alternative ways to code certain parts of the UI. The biggest suggestion would be in how the Wizards are set up.

Obstacles Encountered:

· Trying to understand how everything will eventually fit together when there are unimplemented items.

Solutions Proposed:

I suggest changing how the wizards interact. Currently the pages of the wizard just act as containers, and when the wizard is finished the main wizard class gets their information and sets up the factories. I suggest changing that so that the panels of the wizard contain a method which sets a factory which is handed to them.
Go talk to the UI group directly and get them to understand what you are suggesting.

Development Process

What’s Working: I think the code review is a great idea. By going through the code I was able to see what I, as a member of the model team, had to get done in order to get the UI into better shape. Also since I know how the model is setup, I could add insight into how the UI should be setup.

What’s not Working: Hacks, poor documentation, and not treating unimplemented code as actual code.

To Change: We need to start cracking down on documentation and good coding style. There were instances of classes, that while not in use currently, had horrid documenting and coding styles. This goes for everyone, not just the UI. Whenever we make a piece of code, no matter what it’s for we need to document, why it’s there, what it does etc.

Nice journal.

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

Milestone:

Code Review(in Process should be done by Friday night)
Gains Made:

Met with the people working on Model code review and looked over the Behaviors and Attributes folders. See my code review for the results. Several Model Group people were on hand to field questions and that was helpful.
Worked on debugging the RemotingHub to fix our problems with events. I did lots of print line debugging to find where the error was and then I managed to fix it. It turns out that our Microsoft approved hack for remoting was working but that we were not initializing everything correctly.
Will and I tested a small message passing application over the network and it appears that the NetHub and its library work when given correct input.

Obstacles Encountered:

It’s beerbike week and the week after spring break so it was very hard to work.
Again, I had to sift through Microsoft’s fix for remoting. It is a big hack so it was a little annoying.
Figuring out what exactly I should be doing for the code review.

Solutions Proposed:

The AR group needs to work on making our code more robust and also working with Jim on integrating our new system.

Development Process:

What seems to be working?

The NetworkingHub!
I feel like I know the model code and the theory behind it a lot better now. It was also nice to have some feedback on our code in class today. Hopefully it will be integrated well.

What seems to not be working?

I’m ready to start working on our code some more and we need to get some tasking done pretty soon.

Proposals for change:

I think everything is going well, but we need to find a place where we want to end up with the project. We don’t have that much time left. Things are starting to come together so hopefully we will start getting some specific behaviors that we want coded and track down our random errors.

Nice journal.

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

· Milestone Status:

o Gains: Working on the CodeReview has been a change of pace. Will reports that the NetworkingHub is working now, so that’s a nice place to be at. I think having our code reviewed is definitely a positive contribution to the design process.

o Obstacles: The obvious shortcomings this week are probably most caused by Willy Week (the week that precedes BeerBike). Time is not really a huge commodity, and I wish I had time to review the code more. I also don’t know what other suggestions are being made, and whether or not I really feel that I “productively contribute”, as there are three other students reviewing the same chunk of code. I also encountered some difficulty finding the pertinent UI documentation.
The point the code review is not about having 4 pairs of eyes but rather about having 4 different brains. What we want is for people to express the individual way in which they each view the code.

o Proposed solution: Maybe we should find a more systematic way to organize documentation, such as UML diagrams, “API References” (whatever the .NET thing is called that corresponds to Javadoc), etc. Fishing through my Inbox is definitely not the right way to go. Or maybe it’s just my fault for not subscribing to all of Comp410 on DevHood – I was only subscribed to the AR group thread prior to today, thinking that class-wide notifications would be sent through the listserv. Either way, it’s confusing about where to look for things.
Consistent communications channels is very important.

· Development Process:

o What’s working: Cancelling lab was nice :-P

Process-wise, I think it was nice to take a break from development, and reassess how we got to where we are.

o What’s not working: Maybe the code reviews should have been done in pairs or grouped (all together). That way we can all generate a collaborative summary. Either way, I regret not taking the initiative to try to do something like that, it would have made me feel better against making redundant observations. On the other hand, you don’t want your views to be swayed by someone else. The review of the model code is an interesting compromise of individual work and group consensus.

o Proposals for change: (see above for part of the “proposal” embedded in the “not working” part). Either that, or we should have further delegated responsibilities – maybe one person assess the overall design, a couple of people assess the actual implementation, etc. The lack of “group leaders” over the code-review teams also made it easier for people to not take the lead in organizing something collaborative. I think, personally, that I’m acclimated to having a group leader “take the initiative”.
Don’t ever be a passive follower. Be pro-active in everything you do.

Nice journal.

----- RJMORGAN --------------------------------------------------------------------------------

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

Development Status

There’s not a lot to report this week, because of the code freeze. I’ve spent some time thinking about what’s next, and the things we talked about in class today in addition to the actual reviews of the model code should make it easy to figure out new taskings at the beginning of next week.

I think that we’ll have several people assigned to designing the concrete classes that we’re going to end up using – new behaviors, attributes, etc. We also need to start integrating the AR group’s new code for communications. I want to spend a little more time working on the factories – It might be useful to incorporate some of the GUI into the people builders (basically making them self configuring). I’ll talk to the UI group some and see what they think.

Process Analysis

I think that having a code freeze was a good idea. Preparing for it forced us to clean up our code some, and it gave us time to look at the big picture of everything that’s going on. I’m actually very satisfied with how the code looks right now.

I think that having people work on the code review as individuals isn’t the best idea. There was so much code that I couldn’t look into it in as much detail as I’d have liked too, simply because it would have taken too long to report everything. (And I was looking at the AR code, which is the smallest piece.) For the next review, I think we should have people go through the code in pairs and turn in only one report per group. Then everyone would still look over as much code, but we’d have to spend less time reporting what we found and could be more detailed in the portion of the report that we did write.
It’s not clear to me that this suggestion helps people cover more code – or is the savings just in the time to write the report?

Nice journal.

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

Gains Made

· I finally finished writing the code review for the UI group. I hope it helps.

· I’ve gotten a better understanding of how the UI was designed and how the model is supposed to interact with it. There are some things that I didn’t know were expected of the model, so it was good to both get on the same page.

· The oral code review in class was good to go over what we needed to get done and to see the status of the AR group as well.

Obstacles Encountered

· Some of the UI group’s code did not have much documentation in it so it took a bit longer to figure out what it was doing. Also, I didn’t find a test directory that ran all of the UI’s wizards and such. It would be nice to be able to see the wizards run.
Everyone should take note of this!

· Some of the code didn’t seem to follow what I originally thought it should do and others addressed issues I hadn’t thought of before. It was good in forcing reevaluation of how certain aspects of the project were designed on both ends.
A side purpose of a code review is to get everyone back on the same page.

Solutions Proposed

· It seems like since this was a decently large amount of code to review and that the next code review (if we have one) would be even larger, perhaps each group should be broken down more.

· This is probably too late, but we probably should (have) adopted documentation or variable and method naming conventions. Many of the UI variables were not incredibly descriptive.
Software houses often have standardized naming conventions to make it easier for other in the company to read the software.

Nice observations, but a little too late to do any good.

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

· Milestone Status:

Gains: This week was pretty much dedicated to making a code review for the AR Group’s code. During the previous week gains were made in rendering a full mall view and giving clients a layout from the mall server.

o Obstacles: Aside from normal coding obstacles, there were no truly huge obstacles aside from a shorter week for me.

Proposed solution: The proposed solution this time is to just work as hard as I have been working. Everything else will be worked out.
Is the issue here “working hard” or is it “time management”?

· Development Process:

o What’s working: Now a client gets its space’s layout from the mall server. Once the client connects with the server. The server takes a proxy to the client’s space and gives it a layout. A new class MallLayout was created that has a series of objects that implement the ISpaceLayout interface ( the layout of a space. ) The rendering interfaces were also tweaked. There is also a full mall view from the server application ( as expected. )

o What’s not working: As of right now a client cannot ask for a space specifically. The renderer does not render the simulation on a asynchronous clock yet. And all of this functionality is based off of the old RemotingLib project, not the new NetHub and NetworkingHubLib projects.

o Proposals for change: Having a space to have a specific key in the MallLayout is one solution for picking out a space out of a layout. I’m leery of keyed approaches. Do you really need a key or would a reference to the actual object work just as well? The asynchronous clock is another issue here. First the refresh rate of the monitor for the particular computer that the application is running on must be known. Then we can have some incremental smooth interpolation of positions. But I have to look at the API for that. And whenever the Jim works on the Model / Networking code, we need to discuss some issues.
Don’t get bogged down in fine polishing of the code. Make sure that fundamentally, you code delivers what is needed. Adjust the tasking of the people so that they get the goods delivered. Having one fine part with a bunch of non-working ones doesn’t make sense.

Nice journal.

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

Milestone (3b) Status:

Gains Made:

Development outside the code freeze has led to a working implementation of the NetHub architecture – including pushing objects between two machines, using two client processes and two hubs, one on each machine. It works! Yeah! J

Obstacles Encountered:

Remoting events were still an issue (though now resolved, or so it seems). There are still issues regarding exception handling, throwing, and all-around “how to handle remoting when it's not behaving exactly the way you want it to” stuff, like closing connections.

Solutions Proposed:

Now that the system works, we need to go in and hammer out the details of how to possibly close connections and also document where exceptions could occur and under what circumstances – these need to be handled by a custom exception hierarchy, which needs to be created.

Development Process:

•What's working:

•Code review is a good idea both because it helps our code get better and it allows me to see what other groups have been up to. When we're engrossed in our own milestones, it's too easy to ignore code you don't use.

•What's NOT working:

•I found it difficult at times during my code review of the Model group mainly because I really hadn't ever looked at their code before. I would have preferred (and asked for) high-level documentation – and overview or something – to accompany the code; I had UML diagrams and inline code comments, but nothing that described how the entire system fit together. To understand the relationship of all the object types and their structure I had to dig through code and see how things were actually implemented – this was frustrating.

•Not everyone knows what they're looking at – and this goes for pretty much every code review group. If someone doesn't know which classes are part of the .NET framework versus those that we ourselves wrote, then they cannot provide an accurate code review because they lack comprehension of what they're reviewing. This lack of knowledge leads to confusion on the part of reviewers and inaccurate comments provided to the code owners.

•Proposed Solutions:

•Perhaps future code review groups should contain at least one (and probably no more than one) member who was involved in writing the code to be reviewed; that way, questions can be answered locally in the event of missing, misleading, or incorrect documentation.
A “coach” as someone else mentioned.

Nice journal.

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

· Quality of documentation makes all the difference.

· Keep your eyes on the prize – remember what has to be done and don’t waste time on side issues.

· Remember we only have 5 weeks left. That means only one more milestone after this next one.

· PocketPC’s!!! Got to start coding for them!

· People had some good ideas on how to make code reviewing more effective, particularly the suggestions involving a “coach”. This is essentially inter-team liaisons, which have been used quite effectively in other instances.