Fall 2007

• The backend owns its code now and are fixing various issues. Furthermore, they are proactively pursuing new design decisions, and I'm very pleased with their progress since last week.
• The search team has seen the first real functionality come online as we found the right model for them to represent abstract searches, and I believe this will move us forward from now on.
• We now have Sohum in charge of managing the user experience with the site, which is something that was conspicuosly missing from the original assignments.
• We have also made proactive team decisions (such as? --Chelsea), which is moving us towards a more fluid team structure I think will keep us rolling and addressing the pressing issues.

• I completed my assigned milestones for Tuesday as can be derived from my milestone report
• I began working on creating a UI for the whole site. While it is still a work in progress, I have tried to construct it abstractly enough so that we can just drag and drop ASP themes to change the look and feel of the site.
• I met with the customer on Wednesday over lunch to get his feedback on UI (based on the mockups we had created for meetings).
• The customer was thinking about PlanetTeach with an apple for the ain teach. He sent us a powerpoint regarding the same which has been forwarded to the owlspace listserve.
• The customer was increasingly wary about the visual model of depicting search results as he thought it would correspond too closely with Visual Thesaurus and cause legal issues.
• From an overall perspective, Derek added tag-scrolling, which was quite cool. This is viewable here.
• Rae+Backend were able to get tree-based search working which was also pretty awesome. I feel the algorithms have been written abstractly enough that we will be able to develop a powerful search method.

• Composed a document outlining the differences between the various stored procedures in SQL Server (found here)
• Added an image content type to the backend
• Mulled over some ideas of what tagging should support (to be finalized and implemented this week)  Are these "mullings" recorded anywhere?  What value are they to the project if they vaporize into thin air?  -- SW 
• We finally have a feature specification
• We have a timeline

• I researched into RDF and SPARQL to help in fully understanding how it can be implemented, and worked into our current system.  Documentation of this research?   Does it really do anyone any good if it's all "in your head"?  -- SW
• I met with Rae and explained my position on the matter, which she then worked out with Brad and the backend to put something together - namely searching through abstract trees.

• Attended customer meeting
• Attended customer prep meeting
• Redoubled efforts to make a progress bar with Yuan
• Coded a tentative profile creation page missing the backend functionality

1. I was not able to get as much UI-related work as I wished to. This was due to a couple of reasons.
• Figuring out ASP's theming engine.
• Not having any sort of real milestones because my position was determined mid-milestone.
• Having to fix broken code from other modules while trying to work on UI design.  Where were the people that wrote that broken code?  They should have been there fixing it, not you.  -- SW
2. We also checked in new, untested code the day of the meeting. Untested code should not be checked in, and least of all on the day of the customer meeting.  In Comp410 past, checking-in broken code was cause for threats of grievous bodily harm! 

• I don't know any Silverlight, so I may have to wait on Derek at some point to create a taggable video display. For now, I'm displaying a "preview" of the video in an iframe.  Is it a good idea to have all the Silverlight technology tied up in Derek?  What happens if he gets sick or has a term paper due?   It is probably time well invested to have you or someone else learn the Silverlight technology from Derek.  -- SW
• I think I did a better job of distributing milestones to my team this week, but I'm still not sure whether I did it fairly. I need to stay in touch with my team to find out. (BTW, as I'm a team leader, I feel that this is part of my milestone).

1. The search and navigation team, to phrase it in terms of a certain horrible movie, is in a constant state of flux. At first we were losing Sohum, so we were prepping for that a bit and I started researching more towards stuff that could be used in the future, while Sohum took care of the more concrete bits. Then we gained half of Derek (since he's still part of another team), and now I'm leaving as well. But the new team that I'm assigned to at least is based on what I have researched this week.
2. A lot of what I needed to accomplish this week was very loose and research based. There was some confusion, but I got done what needed to be done, and was able to help out Rae a little bit.
3. Apparently bad customer meeting. Is it really fair to say "apparently"? I think it's time to admit that the customer has some legitimate points. Also, is this really a milestone issue? --Chelsea
4. So if you go on an airplane while sick, apparently all the pressure changes and ear popping makes you susceptible to an ear infection. Blarg. You have an amazingly flimsy immune system =)

• The model we were studying to implement the progress bar relied on an ActiveX object which has major compatibility issues, so we had to scrap that implementation. It turns out the problems of file uploading progress are much much more complex than we gave it credit for. Much of this problem has to do with IIS 6 which has to take in an entire file before it knows crucial file properties like file size before passing it onto ASP.Net. This is the reason there are no built-in controls for monitoring file progress. This has actually created a sizeable market in file upload controls that work around IIS, which means there is a way to do it, but it would take much more time and effort disproportionate to the value of the component to the project.  It is almost always more cost effective to use a third party widget than design one yourself.   Since what research you did clearly showed that third party solutions existed, you should have come to the staff to see if they could be obtained.   Companies are often very willing to donate product for educational use. -- SW Thanks for the full explanation of why this project became a black hole--such an explanation should always be given when so much time yields no implementation.
• A day before the milestone was due, we decided to scrap the file progress bar, and I was reassigned to profile creation. I quickly discovered the handling of users had not been implemented yet in the backend, and it was much too late for any quick remedy to he situation besides leaving a placeholder in the code for where the actual handling of users would take place.
• All in all, my efforts this week yielded very minimal amounts of code that will be used in the project, which is disappointing. Among all the project members, I have contributed the least amount of code.

• I want to continue to foster ownership of people's code and features, and encourage greater stubbing of features so we can define interfaces sooner and increase inter-team communication. How?
• I want to ensure that the time over fall break is used well, and that we can assuage the customer's fears by delivering in a big way. How?
• Now that we have a milestone schedule, I fully intend to keep it up to date and use it to keep people on track

Nice (and hopeful) list, but as Chelsea said, you are completely missing out on the HOW.

1. I think this week will resolve itself since I have began to understand the way I will have to program the frontend.
   • I have looked at official MSDN and unofficial resources on ASP2.0's theming engine and have implemented it. I am still looking for resources that allow me to unleash it in all its power.
   • The UI "team" already has milestones up.
   • Corey's solution of setting a hard deadline for Tuesday seems reasonable. This will also encourage everyone to work harder at the "beginning" of the "work" week rather than the end.
2. We need to encourage self-review before even encouraging code review. For one, code that builds does not work. After any structural change is made, the first thing that must be done is a use-case must be run on it. For example, search would just create a browser interface and try running a couple of searches. Content would try a couple of GUIDs and see if they displayed correctly. Each team had frontend pages set up for testing, so they should have been used before committing core code changes.   Unit tests anyone?   Note that VS can do unit testing of ASP.NET pages: http://msdn2.microsoft.com/en-us/library/ms182526(VS.80).aspx 

• The View team is working on an ASP.NET control that can be plugged in anywhere which serves as a video player. Our team would probably have to figure out a way to interact with that to make video taggable (probably with input from Derek and his pool of knowledge).
• I liked the idea that I brought during class about daily milestone reports, but I also kinda feel that it's a little authoritative and micromanagy (if that's even a word). I think I'll bring it up at the coding party again and see what the feeling is.  It's micromanaging if an edict comes from the top down.   It's team building if the desire to communicate comes from the bottom up.  Maybe you're going about this in the wrong way? 

1. We're just going to have to ride it out. I'll maintain contact with Rae, since a lot of what happens in searching has to do with the relationship model. I need to explore a few things, listed next.   Is "hope for the best" really an effective technique for insuring a positive outcome?  You don't have time to be passive about this.  Be pro-active and make things happen!
2. I've set out three major things that I need to accomplish for this weekend in preparation of the next customer meeting, and the team changeover. Firstly, I need to come up with a concrete plan for calculating trust and relationship costs (at least using functions and such) - this should answer Scanlon's user case at the very least. Secondly, I need to consider RDF and SPARQL, and how they fit into the picture with the relationship model - the model will likely have to be redesigned. Thirdly, I need to speak with Aaron and decide what will be needed from the backend - make sure that it can and will get done someway or somehow. All of this will be posted as my milestone, and will be consulted with Rae as soon as she gets back from her short trip.
3. Brad and Matt are working on a response, which should hopefully happen soon. The sooner we can communicate our awareness of these issues (at the very least), the better. We talked about it in class, and will likely continue to have discussions on how to improve upon many of the areas highlighted as well as our own functionality as a group.
4. Amoxicillin. Check.

• I think some degree of research into the problem of file uploading would have mitigated the amount of wasted effort we put into it. A valuable amount of time was spent going through different possible implementation, and discovering they did not fit the project, before realizing the fundamental obstacle preventing this type of control was IIS itself.
• The last minute swap in milestone goals felt very much like a last ditch effort to get something accomplished in time for a deadline, which sounds pretty superficial, but when you're working with a customer who wants tangible deliverables every week, (as all customers will) it becomes a necessity to work with deadlines while keeping in mind the more long term goals you are trying to achieve.  Good point.

• Complete feature specification - I think this gives everyone, including me, a lot of comfort in knowing exactly how far we are (which is farther than I thought) and how far we have to go. It also shows us where we have abundance or lack of human resources
• Project timeline - This is important especially for me, as it helps me plan what we'll be doing for the next few weeks, and it gives me better forward indicators if we're falling behind.
• Selecting Sohum to manage the user interface has been a great success, as he's really taken off with it, and it's improving our site's cohesion and giving us a better vision of where we're going. Out of curiosity, how exactly does having a new UI lead contribute to "cohesion", and what exactly do you mean by that word? I'm pretty sure the very thing you're having problems with is integration, aka cohesion...so you may be putting a bit much faith in the effects of an impressive UI.

• Milestones seem to be more particular.
• Brad's huge timeline gives us a bigger picture of the project. It also shows us how little time we have and hopefully it encourages us to work rather harder than sit around in despair.
• Each team seems to be coding well. For example, this is the first week that we have seen concrete and working code from 3 of the 4 teams (backend, search, content). I'm not sure what authoring were up to or if I have just been a little ignorant.

• Class time is a lot more productive now. Brad is doing a much better job of handling this.
• Integration is working much better than I expected and, even though there are definitely still kinks to work out, we seem to be moving well in that respect.

• Even though the demo presented to the customer was largely regarded as a failure, I still believe it was very impressive how seamlessly parts of the project were integrated together through a beautiful UI. The errors were there, but so was the proof that all these things we are working on can be integrated in an elegant manner.

It should be understood that the UI however "beautiful" does not truly consitute a system integration because the features it shows for the most part, are all decoupled sub-systems.   The new UI doesn't prove that the those sub-systems all interoperate properly.   In order to truly show a system integration, the value system and the search system must be operational because these sub-systems/modules require that all the other modules adhere to their designated interfaces and provide the correct functionality.    That is, these modules, more than any other, require the proper interoperability required for a system integration.

• Dealing with customer demands/deliverables has been a serious issue for us, as it has consistently cost us time on Wednesdays and Thursdays from working on future milestones, and I don't know what do do about it. Yes, maybe it is, but that's a part of what this class is about.
• I think the team structure has become something of an impediment in some ways, particularly with content view and authoring needing a better pairing and search encompassing what is increasingly looking like two separate but intertwined fields

1. Communication with the customer seems to be our biggest issue at the moment. I am particularly peeved that the customer always seems to get annoyed after everything seems to be dandy. For example, he posted his comment about talking to himself just a couple of days after a customer meeting. He posted his angry letter the day after a customer meeting in which he seemed to be in a great mood.  Unfortunately, the customer often doesn't realize what didn't happen in the meeting until afterwards.  This is partially due to vague deliverables specs combined with a vague meeting agenda that doesn't clearly relate to the deliverables specs.   What do you think can be done to alleviate this problem? 
2. I haven't really communicated with the other teams regarding UI. This is my fault. However, I don't find it efficient to converse over email or IM about decisions that must be made immediately. That brings me to the next point.
3. We dissolved our coding party after one episode. That, or we did not effectively communicate the event of a coding party. I think the coding party is the best time to get work done because it emulates a real workplace the most.
4. We need to be careful with our emotions during customer meetings, or at least how we portray them. I feel the customer's not happy email had quite a bit to do with his wife bringing up minute details that were treated quite sternly by our team. I think it's an important human interaction skill to keep the customer in your good books.  Good point.  The class does have a tendency to come across as overly arrogant at times. 

• Giving Kevin and Yuan the progress bar to work on last week was a miserable failure. Why? I got most of my things done for authoring, but they basically did their "new" milestones (once Brad decided to take away the progress bar) in two days. Although part of the reason was that they started a little late, I also feel that I could have pushed a little harder or been more involved.
• I'm not sure how involved to get with the milestones I give my team. I'm working with very talented people and I don't want to patronize them by trying to stay on top of their milestones as much as possible or by being at every meeting that they need to schedule with other teams, but I get the feeling sometimes that they're not sure what they're doing or how to handle these meetings. This is an important point to consider--there is no easy answer to offer here, but you're definitely on the right track if you're noticing the tension. It's a sign of good leadership that you're tuned in enough to recognize there may be a problem here; I'm sure as the weeks go by, things will fall into place as long as you're sensitive to the issue.
• We NEED to get more input from everyone in the class. If this means Brad stops talking for a little bit and asks for opinions (maybe even picking a person from the class), then so be it.
• We still aren't taking this as seriously as I think we should (myself included big-time). It still seems like many of us are completing our milestones as if they were projects for a regular class (do the minimum possible to pass and stop there) while we need to go beyond that to make this project successful.

• I feel as though we were getting very mixed signals from our customer. On the one hand, he actually seemed quite content and understanding in our customer meeting. He seemed to understand that making deliverables and proofs of concept should not get in the way of our long term goals, and actually said he was fine with not getting the same amount of deliverables every week as long as the project was being kept on track. In the letter he wrote to the class, he seemed extremely irate, and reinforced concepts of polished deliverables and professional standards.

I think you're misinterpreting the customer's remarks here.  He's not talking about deliverables for the sake of deliverables.  He's talking about timely delivery of proof-of-concept capabilities for business-crucial features.  That is, he's talking about those deliverables that are centric to proving that the project is on track. It should also be noted that the customer didn't say that promised deliverables may be left aside; he said that the number of deliverables requested per week may be discussed and sometimes altered, with his prior blessing.

• We need to work harder to show the customer what we're doing so that he can appreciate that we ARE making progress. At the same time, we do need to work better to have demos that are interesting, well planned, and demonstrate new functionality effectively. How?
• We are in the process of reorganizing teams to more effectively address the issues coming up: Content view and authoring will be merged under Felipe, and Corey will take relationship responsibilities from Rae so that she can concentrate on search. Make sure you don't come to rely exclusively on team reorganization to solve all of your problems. Teams should be thought out far enough in advance that they don't need to be altered every other week.

1. We need to bring up the very important point with our customer that we are all full-time college students, not full-time workers. While this is a "real-world" type of class, that does not mean we can ignore all our other commitments. Hence, expecting the same sort of productivity that he would have for $120,000 in the real world is quite an unfair expectation to us. We also need to take technical details out of meetings because I feel this distracts the customer a lot and he ends up worrying about things to much and hence we have the "not happy" mail.  Good point.  Be sure the customer understands your constraints.
2. I'm going to open better channels with all three teams over the next week. For one, I'm going to try and have most of the ASPX pages up by Tuesday, along with filler panels so that each group will know exactly what is expected to be found on each page. I feel this, rather than Photoshop, will be a better way to envision the data in the frontend.
3. We are evidently having a coding party towards the end of midterm recess (on Monday or Tuesday).
4. We just need to learn from our mistakes. We have to realize that customers have different priorities and perspectives from the developers and deal with them as amicably as possible whilst maintaining the magnitude of our abilities (for example, we shouldn't just promise everything they ask, to be nice to them).  Great point!

• I think I did a better job of assigning milestones this week, so we'll see how that pans out.
• I'll talk to my team about how comfortable they feel and if they want/need more support. If that's the case, then I need to assign more coding to them than me so I can serve as a manger more than coder.  Be pro-active about getting their feedback.  I.e. go extract it out of them rather than waiting passively for them to bring it to you.
• I'll try to be a force during class that makes other people talk. I think I'll bring this up to Brad and maybe even be the one that asks what other people think.  Good idea!
• The last one is tricky, but I think it begins with a few people getting motivated and pushing everyone else over the bar. I think that I can try getting my team to do this and maybe we'll get others to feel the same way.  You're talking about building a culture.  Never an easy thing to do, usually done best from the get-go and usually difficult to retrofit in.   But well worth the effort.

• As Dr. Wong has told us in class, the other teams must write stub code instead of waiting for functionality to appear in the backend. We simply don't have the luxury of waiting. Another thing other teams should do is let the backend team know exactly what functionality they expect.
• As for our customer, we have recently began posting on the customer resource site. Matt and Brad are working on a response to the e-mail he sent us.
• We should have a dry run of our presentations before we present to the customer. So far, our presentations have been put together at the last minute. If something breaks, we have very little time to solve the problem before we present. If what we present in a meeting is similar to what we presented in the last meeting, we really need to focus on what has changed, especially if it's not immediately obvious.
• Once we have milestones completed, we need to set new milestones immediately so that we at least have an idea of what we need to do even if we don't do it yet.
• We really need to make sure that our deliverables are complete by meeting time. We should negotiate or discuss our deliverables with the customer during meetings to ensure that they dovetail with our milestones for the coming week. I think this bullet, the previous one, and the first one are all part of a single, elegant solution (though it's not necessarily an easy one to implement). Milestones, deliverables, and communication between teams are definitely related.

Very good points made.   Now what can you do to make these solutions really achievable? 

• The customer is right in many regards. We acknowledged in class that we have to be more prepared with our deliverables, testing and polishing them before the meetings to avoid the issues we had this week. Professional standards are something I know I am not accustomed to, but will have to work towards to maintain a good relationship with the customer. This of course has to be kept within reason. We are obviously full time students and not professional coders. I recognize that I have duties and obligations to fulfill for this project, but I will not go so far as to sacrifice my other classes to accomplish this.   Think of yourselves in the situation of working on multiple projects at once and that you need to allocate your time for maximum benefit for all the forces on you.   As multiple simultaneous projects is quite common for a developer, you should figure out how to deal with it now because the problem is not going away when you enter the workforce. Also, keep in mind that if you had a huge deadline coming up for one of your other CS projects classes, you'd probably be much more willing to put in longer hours if the thing didn't work. Remember that having a team of 13 rather than 2 doesn't alleviate you from being held to the same standards as those in other classes.

Another think to consider is how communications, or lack thereof, figures into how you feel right now.   Have your time constraints been clearly communicated to the customer?  All customers want to believe that their developer is working soley on their project, even though that is rarely true.