|
|
|
1. Name
|
| | Jeeyun Lim |
| | | 1 (8%) | |
|
|
| | Brad Dodson |
| | | 1 (8%) | |
|
|
| | Aaron Cottle |
| | | 1 (8%) | |
|
|
| | Sohum Misra |
| | | 1 (8%) | |
|
|
| | Felipe Serrano |
| | | 1 (8%) | |
|
|
| | Matt Freeburg |
| | | 1 (8%) | |
|
|
| | Kevin Le |
| | | 1 (8%) | |
|
|
| | Corey Shaw |
| | | 1 (8%) | |
|
|
| | Dave Eng |
| | | 1 (8%) | |
|
|
| | Yuan Gao |
| | | 1 (8%) | |
|
|
| | Hubert Lee |
| | | 1 (8%) | |
|
|
| | Derek Sessions |
| | | 1 (8%) | |
|
|
| | Rae Alty |
| | | 1 (8%) | |
|
|
Total: 13 |
2. Milestone Status: Gains made (If possible, include hyperlinks to what you mention here.)
|
| | The UI team was able to - Implement a new theme and test the concept of switching off themes: now the website has a new theme and you can view it here. (It looks nice, though I thought I'd let you know that there's a problem with resizing when the user changes the text size in their browser. -- SW)- Start brainstorming on logo ideas: I came up with rough sketch of two logo ideas and we are also holding a logo contest. - create a data flow diagram of the user's experience on the website: in particular, it is a visual representation of how a user might navigate from the main website to logging in to arriving at a content page, as there are several different paths a user can take to get to a content page. The diagram can be found here. That diagram is really useful. You should really put it as a web page on the site, ala "site map". -- SW |
| | | 1 (8%) | |
|
|
| | I have specific milestones this week!!:
here
On these, I've not accomplished too much really concretely yet, but I have thought about them.
On other fronts, we've seen a lot progress on the relationship system this week, which was one of my key goals. The query interface to it from the backend is working and the relationships team is busy writing interfaces to all of the components that will build upon this system. I was especially happy that the search trees came along and the design adapted relatively well (from what I can tell) to the needs for querying even with relationships.
Additionally, people seem to be investing more in the project from what I can tell, and we're quickly solving a lot of the bottlenecks that held us back before.
|
| | | 1 (8%) | |
|
|
| | My milestone report, while reflecting the progress that I had completed by midnight on Tuesday, is wholly inadequate about the progress made this week. A lot happened on Wednesday and Thursday. Shouldn't the Wed+Thurs work be on this week's milestone report, not last week's? I smell some funny accounting here. -- SW I believe what you are trying to say here is that you are linking your milestone report but have a lot more to say here that will also be on the milestone report due on Wednesday, yes? --KristinWe decided on a pretty good interface over the weekend, finally giving the backend team something concrete that we could work toward. This still needs to be polished, and we need to decide whether it's better to have multiple tables or a single large table, but we made huge progress. The decision on whether to have one or several tables should be based on whether or not the system is properly normalized. Go find the steps to normalize database tables. I believe there are 7 steps total, but you really only need the first 3 or 4. -- SW We worked hard, and aside from a few bugs we fixed after the merge, all functionality was complete on Tuesday. The backend now can process SPARQL statements, generate SQL from them, execute them, and provide the information back to the relation team. For once, the backend is working flawlessly and all of the problems are coming from the frontend. ...Okay, maybe that's not quite true, but we're a whole lot closer to that this week than ever before. So...did I misunderstand your statement above? Where is your report on all the work that happened on Wednesday and Thursday? |
| | | 1 (8%) | |
|
|
| |
- Milestone report can be found here.
- UI team was able to implement a new theme pretty easily, and this was a good demonstration of the ability to drop in themes, for the most part (this will be addressed later).
- I implemented a clearer way to separate authenticated pages (pages that differ based on user authentication state). I'm thinking about going ahead and making every page authenticated-ble. That is, every page can feasibly have a different action depending on user authentication state.
- I looked into and found that ASP.NET had its own validation framework for forms. This will help as I will not have to develop my ValidationPage class anymore. I'm hoping to make these changes this week.
|
| | | 1 (8%) | |
|
|
| | After the milestone deadline on Tuesday (for which I had completed only the content conversion on my system) I sat down and worked hard on this as I had gone through most of my commitments for the week.
I revamped documentation and uploaded it to the Sharepoint. (I still have to look at Search documentation more in depth, but after talking to a few people I know more of what's going on in there to keep documentation going).
I also merged my conversion code into Skynet 3 (It was actually more painful than I expected, since Skynet 3 is 64-bit XP and I'm running on 32-bit Vista, but I think that helped me to make my implementation as general and inclusive as possible for future deployments)
In addition, I added functionality to upload and text editor so that it includes the currently logged in user as the author of the content created. |
| | | 1 (8%) | |
|
|
| | I'm physically exhausted after this week, so this journal is going to be straight to the point and then I'm straight to sleep. I have a milestone report here. This only reflects a small portion of everything that happened this week. Here are other things (and I'm having trouble remembering a whole lot at this point): - met with Luke and Sohum and Jee Yun on monday to talk about UI - received much materials from Luke which were posted on the sharepoint (still need to do one more) - much phone calls and email between Luke and I - coded up a quick way to show that we can get trust one and two jumps out, so Sohum could display that on profile page for the demo - met with many people for many different things and questions what felt like almost all the time around every corner (questions about how stuff worked, what to do, various code problems) - team leader meeting on thursday - came up with some milestones for Brad that still need to be posted formally (that is next) - tried to help Dave with presentation notes |
| | | 1 (8%) | |
|
|
| |
- The relationship team worked extensively with the backend to define the requirements for the interfaces on which the relationship model can operate. Interfaces on the backend and relationship model are in place to handle simple cases of trust.
- Drafted a document describing purpose and potential factors to be used in our value system.
- Communicating with the search team on representing relationships in search trees. Vague. What exactly does "communicating" mean here? Be specific, especially in light of the lack of communication that you detail later. -- SW
|
| | | 1 (8%) | |
|
|
| | Even though not much got done for last week's milestone, in the time since my team was able to:
- Get a basic functionality for search tree parsing, so we were able to demo search at the meeting
- The start of an implementation for the relationship interface and how it uses the backend
- A basic idea of the value system |
| | | 1 (8%) | |
|
|
| | Milestone report can be found here. We got a proof of concept of search working! That implies a working tree parser, and working interface with the backend! Woo! In addition to this, I prepared a presentation for the customer meeting. The relationship model team has its purpose. We know better what we're doing now, and I feel that we're a lot closer to the end goal of a fully implemented system than we were last week. |
| | | 1 (8%) | |
|
|
| |
My milestone can be found here After Tuesday, I added preview function to the embed content plugin so users can preview the content before they insert it. I also fixed several bugs in WYSIWYG editor (can't recognize multiple embed content, error messages in table plugin), check GUID before insertion in embed content plugin, and change the background color of TagContent page to light grey. I also added image plugin for WYSIWYG editor, so we could adjust the height, width and alignment of embedded image content. I demostrated the functionalities of WYSIWYG editor to the customer in customer meeting. |
| | | 1 (8%) | |
|
|
| |
- Met with a portion of the team (relationships, search, and backend) to discuss the integration of relationships/RDF into the backend
- Met with Aaron and Matt about the redefinition of the backend implementation and changes to the database
- Created a class representing a Sparql query statement, added basic functionality
- Created a class representing a query on the backend
- Created an interface for validating a Sparql query
- Added comparison content enum
- Created an interface representing a member of a Sparql query
- Created concrete implementations of the interface
Good detail here. Try getting this level of detail into your development process sections as well. --Kristin |
| | | 1 (8%) | |
|
|
| | My milestone report can be found here I'm going to be finishing off the basic ContentAppraiser by Sunday. At this point all that is going wrong is saving the result, which should be easy to fix. With that, my code also has to be cleaned up a bit; I was trying to quickly fix bugs and left it a bit of a mess (a more working mess, but a mess none-the-less.) On Sunday I'll start more large scale tests of the code as we upload more and more content and relations. And, of course, I'll be helping out to get search up to 100% and probably work on the Silverlight player this week if Sohum has time since the GUI needs to be redone for it. |
| | | 1 (8%) | |
|
|
| | -We (Brad, Aaron, Matt and I) completed and agreed upon the model for search trees. This was communicated to Corey and the Relationship team (what about the severe delay that Corey was so unhappy about in his journal?), so that they could figure out parsing of it into the new SPARQL-like Statements. This should be the actual final (yay!). Documentation for this is found in Examples of Search Trees, which includes examples, how to create them, and what they should be translated into (Statement wise). The actual description of the trees can be found here. -I redesigned the way selection parameters (formerly search parameters) work, and re-wrote the search parser (formerly search factory) accordingly. I e-mailed this description to Sohum so that he could remodel the view accordingly. The e-mail can be found here -We (all except Authoring team) managed to integrate Search from one end to the other! A search now successfully goes from the View (where user input is translated to parameters) to Search (where the search trees are constructed) to the Relationship (where the trees are translated to SPARQL-like Statements) to the Backend (where these statements are translated to SQL). There is not much information of the correct for in the backend, so the only test we could perform was searching upon the name of content, but that worked for the four items in the desired form. More testing to come. -We had a customer meeting. See the minutes |
| | | 1 (8%) | |
|
|
Total: 13 |
3. Milestone Status: Obstacles Encountered
|
| | I wasn't given a lot of coding work to do this week. I understand that Sohum had begun working alone and that it was hard to designate me to do work. I actually appreciated it because I had a take-home test and another project due on Tuesday so I would have been miserable if I had a heavy load for 410 as well this week. Still, I expect to be given more tasks in the future. |
| | | 1 (8%) | |
|
|
| | We've waffled on a number of issues, most of which we don't know the answer to, and probably can't know until we try some options. For instance, we don't know what the performance issues of the triple-store model from the backend perspective will be, and whether we'll be forced to special case certain things to improve the speed with lots of data. We really can't answer this question now, or even pretty soon, so we need to just define the interface and as many pieces so that the system can be adjusted either way with minimal pain, document this decision, and then come back to it later if we have time.
Encapsulate, encapsulate, encapsulate! All optimizations should be done behind encapsulation barriers or they will wreak havoc in the rest of the system. -- SW
We had a number of obstacles this week relating to difficulty communicating. Among them: the Relationship's team inefficacy becuase it was waiting on a backend interface, which should have been solved if they'd made contact sooner.
Still overall we're doing better in this area. This is definitely a development process issue, not a personal milestone issue. --Kristin |
| | | 1 (8%) | |
|
|
| | Unbeknownst to me, there was a problem with the interface we checked into the main branch before we created our own branch on Sunday night (one class wasn't public). While this wasn't really an obstacle for us, this held up the relationship team a lot, and I apologize for that. One way to check for these problems is to check out a clean version in a new workspace and see if you can build it. --Chelsea
The Schlumberger presentation, while very interesting, was also at a bit of an inconvenient time, being the few hours immediately before the customer meeting Thursday. |
| | | 1 (8%) | |
|
|
| |
- I really had to wait quite late before throwing together an advanced search interface because teams were waiting on each other. It also seems a lot of interfaces are throwing "not-implemented" exceptions which is good for testing code out, but not really helpful when preparing customer meetings. Is this "throwing together" still what the class views as "integration"? If so, why is all the integration taking place in the front end?
- We need to think about stubbing code out better. For example, if a search method is not implemented, i would think it semantically more correct to send back an empty list rather than throw an exception or null, from a frontend point of view.
- I have still not tackled the Silverlight player seriously.
|
| | | 1 (8%) | |
|
|
| | I possibly put in a little too much time into the documentation, but I think this will be important in the end...we'll see. You'll be happy about this during finals when you don't have to spend a lot of time you could be using to study for other classes to document everything you did during the semester...since the final, fully documented project is due after the presentation and before the end of finals.
It was much harder than I expected to integrate the conversion code into a different machine. I had hardcoded a lot of constants (you bad boy!--and you paid for it, didn't you? ;-) )that I thought were reasonable, but it turned out I was very off the mark. I had to revamp much of my code that interacted with the external applications so it could be used on more systems (I still have no clue if it's compatible with all systems, but I hope as people test on their machines this will come up).
I also am way over committed this semester and I need to juggle my time a lot more efficiently if we're going to see this through, which I really want to. |
| | | 1 (8%) | |
|
|
| | Coding obstacles are insignificant at this point. (I don't know if I would say they are completely insignificant...) All the real action is in the miscommunications which are development obstacles. There are questions about the database which should have came up a long time ago, but that is a relic of our original mistakes and really more of a development issue. |
| | | 1 (8%) | |
|
|
| |
- Documentation on the search specification was not received until the day before the milestone report was due.
- The proper query interfaces needed for relationships were unusable at first (Vague! Explain please!), and necessitated the commenting out of relationship interfaces in order to keep the build working.
|
| | | 1 (8%) | |
|
|
| | Our problems were in the development process. It's difficult to find problems with our coding since we were unable to do much in the first place... |
| | | 1 (8%) | |
|
|
| | 1. We lost a decent amount of time waiting on other teams both Sunday and Monday. But we were able to get interfaces cranked out on our end, and the proof was in the pudding, so to speak.
2. Other classes - yeah, I know. But they were dealt with.
3. I'd normally like to note the several times the tree was burning and the "surprise" tasks, but this is verging on the state of normalcy at this point. |
| | | 1 (8%) | |
|
|
| | Show preview of embedded content in popup window after insertion. In WYSIWYG editor, when user switch to plain text editor, the embedded content is removed and only left <embed> tag, so when user switch back from plain text editor, they can't preview embedded content. I don't want to fetch the embedded content again, because they take too much space in the editor and fetch them will take too much time.
We want to enable the users to adjust the width/height/alignment of embedded image content, but I'm not sure how to do this. I think we can treat embedded image content as image and use "img" tag instead of "embed" tag. Felipe has a good idea of using CSS. I think my method is simpler to implement but it only works for image content. Felipe's method may be also suitable for text/video content, but it's harder to implement. |
| | | 1 (8%) | |
|
|
| | Apparently, the backend was not quite ready for the customer meeting presentation on Thursday and it fell on Dave and Rae to figure out what was going wrong. Matt and Aaron were both at the Schlumberger site visit that day and I was out of town. I think this is a result of an unclear redefinition of the backend as well as insufficient testing, both on our part and theirs. I guess it boils down to not having a process for resolving integration bugs. |
| | | 1 (8%) | |
|
|
| |
Multi-threaded functionality is annoying to test, as one might suspect. Of course, it doesn't help when you make silly mistakes anyway, which I did. Also, although this isn't an obstacle, I need to do some more documentation on my parts. Things need more than a sentence summary per function (or are they methods in c#? I'm going with function, but please correct me if I'm wrong) I believe methods is the word in C#. Also, you're very right here--documentation is important will come back to bite you, whether it is when you go back to clean up your code or when you are having to frantically document the entire project during finals week, which no one wants to do. --Kristin |
| | | 1 (8%) | |
|
|
| | -It took some thinking and work to figure out a good way to represent the selection parameters that made them worthwhile. That is, a way to fully represent the tree that makes it legitimate to not just make the tree yourself. It also needed to be fully comprehensive, and allow for *any* search tree to be created. |
| | | 1 (8%) | |
|
|
Total: 13 |
4. Milestone Status: Proposed Solutions
|
| | I actually asked for Sohum to give me more work this week and he told me that he had already planned on giving me a lot of work. I will have to work with Sohum and figure out how much work is good to be divided up among the two of us. It's definitely a good thing that you have some input in this--it'll help you both have more manageable milestones. --Kristin I will communicate more with Sohum and make use of our coding party on Sunday so that I make sure that we are on the same page. I am also given the task of figuring out the identity verification process, since we've spent weeks glossing over it as a topic we need to get to, but never actually nailing down the details of it. I will have to manage my time well so that I am not complaining about too much work next journal. =) |
| | | 1 (8%) | |
|
|
| | We need to realize that engineering decisions like the one I mentioned above will have to use best guess answers for now, noted, and returned to when we have the relevant data to make an appropriate decision. We absolutely can't let them hold up our progress toward the team integration goals.
To solve the second issue, we need to do a number of things:
First of all, defining the interfaces early will improve this situation tremendously, as both sides know what they're given and what they need to do. (Yes, this is very important, although you have to wonder why it is already the end of the 7th week of this project and you haven't defined interfaces...) Then the level of communication required is minimized. Secondly we need to encourage people to stay in regular contact, express their difficulties, and identify the factors where people could get held up. The sad thing about the case I mentioned is that, while it only cost a couple of days, Matt and I identified it previously and put special effort into trying to address it, but apparently not well enough. |
| | | 1 (8%) | |
|
|
| | Corey (and others) should hound me relentlessly if the backend is blocking them. It's good to come to Matt, but really, if you can't work, you should be calling me and Hubert too. I heard that there was a problem, but I thought it was the fact that a few classes went missing from the Search team for a while.
In the real world, important meetings don't always happen at convenient times. The best thing we can do is be prepared beforehand and work with the knowledge that life can occasionally interrupt 410. |
| | | 1 (8%) | |
|
|
| |
- There are more varied milestones planned for this week (and the coming week) that will require the UI team to get a lot of work done. Hence, we probably won't be waiting around because there'll always be something to do. This isn't a solution, it's a "hope it doesn't come back and bite us again". 1) and 2) are related. Ask yourself, "why is the front end so dependent on the development cycle of the backend? Should it be, in light of the notion of decoupling the front from the back end?? What is the role of the interfaces here? -- SW
- I think teams have began to do this and the problem has been more or less addressed. If it comes again I will discuss the validity of the issue with Matt and Brad as well as raise my concern with the relevant team.
- It's just something I've been procrastinating since I've not had the data/interfaces I need from other teams ready. This weekend I will have to tackle it since all the interfaces are coming together.
|
| | | 1 (8%) | |
|
|
| | As far as the first problem, I think it may be a problem for now, but I'll probably appreciate the work that I did later on when documentation becomes a key priority.
For the integration problem, maybe some extra initial research may have helped, although I doubt it. I had no clue what I was doing at first, so I think these are just roadblocks that you come to and have to hurdle over them. I also am not sure if I should have asked for help, since most of the bugs were something insidious (e.g. Microsoft Expression can't accept spaces in the command line arguments, but when this happens returns with the very handy exception "System.IO.StreamReader" and there's absolutely no documentation online). I don't think anyone could have gotten this bug from my description of what I was doing.
Other work is hard for all of us, and I think this is a constant problem that we have to work through. I think the best way to handle this is be honest with others. Don't say you'll complete milestones simply because you feel bad, but estimate your time usage realistically. Yes! |
| | | 1 (8%) | |
|
|
| | Fix development issues. Make effective communications. Follow up with written clarification. Check for understanding. Lather. Rinse. Repeat. Coding solutions, fixes to design problems, they all follow organically from this.
Future 410 classes, are you paying attention? Current Comp410 class, are you listening? |
| | | 1 (8%) | |
|
|
| |
- There were major dependency issues during our work this week, and much of the breakdown that happened as a result of this could be attributed to miscommunication. The relationship team did not pursue better interfaces from the backend until it was much too late, and had we been in better contact, these issues could have been resolved before our milestones became due. Then why is this listed as a milestone success? We ran into this problem with the search team as well. We did not communicate our needs to eachother and so did not have the right implementation in place on Tuesday. We could have prevented this by dictating more specifically what our relationship model demanded from the backend instead of having a vague notion of how the two would interoperate.
|
| | | 1 (8%) | |
|
|
| | N/A
Although you did not get a lot done this week, and the rest of your journal has good points, leaving a section blank will never help you (or your teammates)... |
| | | 1 (8%) | |
|
|
| | 1. We (the relationship team) know what we need to do now, and have a clear direction in which to code. Like a cornered quarterback, this week we need to just duck our heads and run (hopefully with positive yardage).
2. Suck it up.
3. Hopefully we have a system now where we can't check in broken code. Hopefully. Where's that dunce cap we were promised? Again, hopefully is a word that tends to always come back and bite 410 students. Are there any concrete solutions here? |
| | | 1 (8%) | |
|
|
| | Maybe I can use AJAX. But fetch the content takes time so we can't place the embedded content as user wanted. I'm thinking of using a label and update the label as we get the content.
I will discuss this with Felipe about this problem. I think either way will do, and we can just try one method and change it if we find it's not good enough. A common method to indicate AJAX calls is using a spinner--try Googling "AJAX spinner. --Chelsea
My milestone can be found here After Tuesday, I added preview function to the embed content plugin so users can preview the content before they insert it. I also fixed several bugs in WYSIWYG editor (can't recognize multiple embed content, error messages in table plugin), check GUID before insertion in embed content plugin, and change the background color of TagContent page to light grey. I also added image plugin for WYSIWYG editor, so we could adjust the height, width and alignment of embedded image content. But what about the issue of embedded video like you mentioned above? -- SW Does this mean you already changed the content to use the "img" tag?I demostrated the functionalities of WYSIWYG editor to the customer in customer meeting. What problem is this solving? -- SW |
| | | 1 (8%) | |
|
|
| | I think one thing we're lacking right now is documentation on how the backend end has changed since it's been redefined. That and we haven't decided on how much RDF/Sparql we should support on our end. We should probably get some up-to-date documentation on the backend once we have everything figured out (or even if we haven't gotten everything figured out).
It's not clear how this addresses the integration bugs issues. -- SW |
| | | 1 (8%) | |
|
|
| | I just need to write an extensive test suite for the system. The most important part is that it runs, second most is it gets the "correct" value, so I just need to make sure there are no race conditions or freeze conditions. After that I'll start optimizing weighting and deciding on algorithms to do the ranking by. |
| | | 1 (8%) | |
|
|
| | -I think my solution works and is beneficial. (The explanation of the solution is found in the Gains Made section) Once Sohum figured out how it worked, his response for the parameters necessary for some simple search was "So it only needs those two parameters? That's spiffy" (I may be slightly misquoting, but the point is he seemed to find it useful enough). |
| | | 1 (8%) | |
|
|
Total: 13 |
5. Development Process: What seems to be working and why?
|
| | As a team we are better about communicating and asking for more information. We know specifically what we need from the other teams and able to ask for them. More phone calls are going back and forth between teams and more meetings are occurring. We did a much better job at integration this week and our customer was happy to see that progress made. We delegated some of the people not on the Customer Relations Team to do the presentation this week, and I think it helped them solidify their overall understanding of the project. I don't mean to say that they didn't know before, but when you have to present it to someone you think more about what is the important part of our project, etc. A good analogy of this would be that teaching something you know helps the teacher understand the topic more clearly. (Interesting point--presentations are more than just for the customer's good! -- SW) |
| | | 1 (8%) | |
|
|
| | We are getting a lot more people committed to seeing this thing through, which is a tremendous help in many ways.
Additionally, personally I've been stepping back to allow people to use their talents more effectively to help the team progress.
Concretely this means I want to let people like Matt and Felipe voice their opinions more clearly, as they're saying the right things. I can't always control myself, but I'm getting better.
Furthermore, this has given me some more time to look at a number of key issues in the project, (good, this is what the PM should be concerned with, not with picking up the slack that other team members have left.) and will even more this week I hope, so that we can avoid future surprises and make implementing the remaining major feature sets a simple task.
Despite the grumblings, the new team layout is much more effective than the previous one from everything I can see, which is probably because the old layout was arranged around my rather skewed view of the central features of the project.
We are growing into a better team too, I think. We are helping each other out more, working together better to prepare for customer meetings, and being more integrated with our development efforts (for the most part). I think this will especailly be true next week (see below for why). |
| | | 1 (8%) | |
|
|
| | People seem motivated this week, and a lot of things coalesced at the last minute. Our work rate is like a playground swing: we do little after the meeting on Thursday, but it builds continuously throughout the week, each week reaching a higher point than the last.
I think the management is becoming more seasoned, and that's helping everyone out. |
| | | 1 (8%) | |
|
|
| |
- It seems like the smaller teams has allowed people to be more focused on what their specific utility to the project is. This has allowed us to be more measurably productive, rather than being assigned research which is usually more of a busywork kind of task. As painful as busy work is, sometimes it saves a lot more misery later on down the road...
- We have been communicating better within teams, unafraid to call up and ask people when we have questions. We also had a better customer meeting, as the customer finally seems to be trusting us.
|
| | | 1 (8%) | |
|
|
| | We keep improving communication and it seems like more people are making an effort to get together and integrate components.
A lot more people are speaking up. This was the main problem early on, but I feel that it's getting better. We still have some work to do, but we've come very far.
The milestone divisions are working great (at least for my team). We have also gotten very good at staying in touch.
Class time use has gotten much better. We seem to have worked out a process and it also helps that we now have a lot more to talk about. |
| | | 1 (8%) | |
|
|
| | There is more communication this week. There are a lot of people stepping up to the plate, but I will reference that in the peer review section.
The amount of emails and phone calls I received this week has increased at least 100% if not more. This is very good. We are just missing the next step of committing it to written format for future reference. And so the rest of the team can know exactly what is going on.
Not only do the teams seem to be coming together internally as many people are noting, but I also saw something else new this week - a lot of the teams are now working together with each other. This actually helps progress a lot, since they can explain code to each other and make fixes on the spot. I think Authoring is the only team that is still kind of out on their own, but I want to change that. So does Felipe. |
| | | 1 (8%) | |
|
|
| |
- The customer demonstration I think proved a successful transition of the search team now utilizing some basic functionality of relationships, which is a revamp of the old system. This proof of concept is a good example of how our goals lined up with something to demonstrate at the customer meeting.
|
| | | 1 (8%) | |
|
|
| | I don't think I've been able to create a very good team spirit with my new team yet. But one thing I did discover is that it's a positive thing for us to just get together and work at the same time. I'm going to adopt this strategy, and instead of having meetings, just have a couple of days per week that we meet in Symonds and work together for a couple of hours. This will reduce the amount of work that we need to split up, and the divergence that will happen in our design. Good idea.
Also, I suggested that we try and rarely branch, if ever, instead having everyone check into the trunk. This forces integration, and reduces the chance someone will develop in their own world, forgetting about others' needs or interfaces, or breaking the build without realizing it. I think most people were on board with this suggestion and I hope it helps us out. Yes, this is a very good idea. Problems get solved continuously throughout the week rather than frantically the hour before the customer meeting when it won't all merge. |
| | | 1 (8%) | |
|
|
| | Our team - the accomplishments made before the customer meeting are a sheer testament to this.
Fun Friday! Wait...this Friday wasn't all that much fun...dammit! Somebody bring Apples to Apples next time...or booze*cough*aaaaaaanyway, I really like the idea and the teambuilding. |
| | | 1 (8%) | |
|
|
| | Our customer was happy about the progress we made this week, since we have showed him the WYSIWYG editor and user profile working.
We have more people paticipated in the customer meeting.
Felipe asked me to send him daily report, I think this is a good idea to improve communication. |
| | | 1 (8%) | |
|
|
| | We have gotten some good progress during our coding parties, since we have everyone (or at least someone from each group) present. It makes it a lot easier for us to coordinate things and define interfaces. |
| | | 1 (8%) | |
|
|
| | Communication is going well, my e-mail box is filling up, which is a good thing. I think it was a good idea brining people who haven't presented up to present at the meetings, especially since we got an awesome demo of the WYSIWYG editor. Also, teams seem to be working out well. It feels like we're really starting to roll along (hopefully this isn't tempting fate.) |
| | | 1 (8%) | |
|
|
| | -Although with some issues, see below, we did manage to integrate the system. That required a lot of communication, and working together. Although the integration was put off way too long, until 1:30-ish on Thursday, we weer able to fix the bugs. And most of the time was spent figuring out what code did. There was very little actual problem in the integration, and nothing required large amounts of re-vamping (only a few lines of code changed or commented out). This mean the communication was good enough that the ideas were properly communicated, and people understood the forms of things well enough to properly (mostly) code their parts. That's actually really good, I think. |
| | | 1 (8%) | |
|
|
Total: 13 |
6. Development Process: What does not seem to be working and why?
|
| | We still seem to have a problem of reconciling the discrepancy between our deliverables and milestones. Dr. Wong brought up a very good point about how misalignment between deliverables and milestones can cause much stress and slow down of development. This was primarily why we had asked for 2 week milestones instead of the 1 week ones we have now, which the customer was not willing to compromise. (Yes and no, the customer agreed to two week deliverable specs, but still wanted tangible results presented after one week. ) I do believe that part of it is that some of us are unable to get much done until the weekend (I am guilty of this). I certainly don't mean to say that everyone is like this and we are trying hard to balance work between this class and other classes in which projects and problem sets are due during the week as well. |
| | | 1 (8%) | |
|
|
| | Some poeple are still living on the fringes of the project, and we're going to need to see some serious output from them if we want to really get going.
The new team layout, despite it's apparent effectiveness, clearly has some serious holes:
The largest and most glaring of these is that no one is in charge of testing. I need to consult a number of people about this, but this needs to be rectified soon. Sohum is not the person to do this, despite the fact that he's good at it, because he already has so much other stuff do to (and just wait until we really get going with his stuff ;-)).
We haven't been as integrated with our development efforts as we probably should be for a number of reasons that I hope to fix in the future:
- Interfaces have taken to long to define, with people waiting on interfaces to be checked-in.
- We have had a number of issues with code breaking due to merges. This should be mostly addressed by not using branches to nearly the extent we had previously, and I hope this will help us.
- Things are still coming together too soon before customer meetings.
|
| | | 1 (8%) | |
|
|
| | While Matt and Brad are assuming new roles (and for the better), I'm having less and less of an idea of what they're doing. Specifically, I have no idea what Brad is doing. I have no doubt it's difficult and time consuming, but from what I can see, he's not running class meetings, he's not running customer meetings, and he's not coding. I'm not saying any of this is bad, but simply that the lack of knowledge of what he is doing is. This is where the idea of Brad posting his own, concrete milestones comes in. Even though he is the PM, there needs to be transparency so the rest of the team can hold him accountable for his milestone goals just as he holds you to yours.
You know, I'm not really sure what I'm doing specifically either, other than the fact that it does take a lot of time. I'm a little uncomfortable with this, but not too much, as I'm having more time to sort out communication problems and interface issues, as well as research architecture solutions. -brad
This issue comes up more in the real world than one would like to admit. At least here, we don't have to pay Brad the big bucks too! ;-) |
| | | 1 (8%) | |
|
|
| |
- I have not been delegating well. Jeeyun had a busy work this week but I will not use that as an excuse. I will need to work on this.
- TFS. This was the week of our (mis-)usage of TFS causing major headaches for all. Branching multiple copies resulted in major problems because interfaces changed in some branches whilst not in others... etc.
- Tempers seemed to flare up a couple of times. This is probably a result of the looming deadline getting closer and closer.
|
| | | 1 (8%) | |
|
|
| | We're still not getting that much accomplished at the team leader meetings. We get off topic too much and sometimes discuss things in way too lengthy detail that precludes us from talking about important stuff (like the imminent customer meeting).
This was definitely not an issue for me, but a few teams had a lot of issues dealing with each other. You just have to read Corey's journal to see some of the sentiments that were felt during this week.
I feel like the customer has completely forgotten about my group and hasn't given us deliverables for a few weeks now, so we're working on what we think would be good. Have you talked to the customer about this (after a meeting or something) to make sure you're headed in the right direction? I understand that the value system is a crucial aspect of the project (and probably the most innovative) but without authoring, you wouldn't have much to "value". I think our group has been isolated from the rest of the class, judging from the fact that no one had any clue that Yuan had a text editor and that Yuan and I had no clue what was going on with the value system/search. (Consider this notion: Can little recognized successes be leveraged to make the customer feel better about more visible failures?)
The Thursday rush was scary...I'm very glad but very surprised we got things working. |
| | | 1 (8%) | |
|
|
| | There is still miscommunication this week. There are problems with our work cycle.
There was a problem in communicating problems that the Relations team was having with the Backend interface. I have to accept some of the blame here, as what I thought I had communicated to Aaron and Corey was not the same as what they received. Aaron was right that he and Corey should have been talking directly about it (they both had other committments that night, which made it more difficult, and the branching situation also made things difficult), but I also think I could have done a better job here.
The lesson is that different people have different communication styles, and I need to be more aware of it (future classes take note here). How you say something can differ a lot from what you really mean, depending on what type of person you are (Luke talks about the personality types - melancholy, choleric, etc. - a lot, relating to this issue). And when you try to communicate with someone who is a different personality type, this often results in the two of you coming away with completely different things in your head about what was said.
The solution for me is to try and think about this more when working with the different team members. Brad and I talked about it a lot with Luke in regards to the two of us working together, and now I need to apply that outwardly. I should also consider whether some problems are more efficiently dealt with if I pass them off to Brad rather than try to solve it on my own. This is probably one of the cases where his communication style would have worked better than mine. |
| | | 1 (8%) | |
|
|
| |
- There was a major rush to fix the broken build for the customer meeting that involved people from different teams scrambling to fix the errors that popped up the night before the customer meeting. A lot of factors played into this, including the issues of merging branched projects back into the main branch, as well as some mysterious rollbacks (possibly also due to merging branched projects).
- We spent a fair amount of time during our customer meeting discussing possibly having a biweekly deliverable schedule instead of a weekly one that was causing us to fall into a pattern of rushing fixes and features to be in place by the customer meeting and then spending the next few days rolling back hacks to the system. You haven't really delved very deep into this. What was the result of this discussion? Is this bad because you spent too much time in the customer meeting talking about it or because you are spending so much time doing hacks and then getting rid of them again?
|
| | | 1 (8%) | |
|
|
| | There are a lot of things that did not work this week. Luckily I'm not as frustrated as I was between Sunday and Tuesday, so this journal will not be as scathing as I would have predicted.
- The backend did not deliver our querying interface in a timely manner. I was under the impression that they would have it delivered by Sunday, so we'd have a few solid days to work with it, and then I find out on Tuesday that "everything is changing" and it's being worked on in a branch - where we can't use the new version. Not to mention, the one we had to work with was not fully public, so we couldn't even call half of what we needed to. So I'll admit, it is partially our fault for not discovering this until Tuesday - we did have a lot of other stuff to define and think about, and I know that I didn't have much time to work on it on Monday. But the most frustrating thing to me is that the interface did not get fixed when it was most needed. I planned to put many hours in on Tuesday, finishing everything up to the best of our ability, yet for 9 hours (from 2:30 when I first talked to Matt until 11:30 when I wrote my milestone report), the interface remained unchanged and unusable. We ended up resorting to committing commented code, that would "in theory" work once the interface was finished.
- Rae did not deliver the documentation for the search trees until late Monday night, leaving us effectively a day to implement a traversal algorithm. There was no way that was going to happen. Even after we didn't get it for the milestone, we still needed it for the customer meeting, and even that was rough. Something ended up working, but I'm not really sure how.
- I think one of the central issues with the backend's inability to deliver an interface was Brad's changing of the relationships design and backend structure. I really, *REALLY* suggest that we stick with a standard, relational database model that we have now, rather than switching to one giant table where "objects" are nonentities and rows are properties. That is a terrible design for so many reasons, the biggest one being performance. I gave a pretty long speech at the meeting on Sunday on why I think it's a bad idea, but Sunday night Brad still wasn't convinced. Lately I think he's coming around a bit to keeping the standard tables around, so I've been a bit eased.
- I tried to make it clear to Kevin, on several occasions, the importance of the Value system report, yet he continued to put it off, and he ended up not even uploading it. I understand that he had a COMP 320 assignment due on Tuesday night (terrible timing), but he could have put in more work on Wednesday and Thursday, and I even offered to have Dave and I help him. He didn't seem to see how important it was to the customer. Would you have settled for a draft report just to temporarily keep you from stalling out? If so, let people know in advance. People have a tendency to not want to release anything that isn't "finished" and "perfect", when in reality, their audience's needs may be for a lot less. -- SW
- I felt like a number of additional tasks were added to my list at the last moment. These are things that never showed up in the team milestones, and others not in the deliverables list. I know that things come up, but I think some of those were unstated things that were expected from my team, and that doesn't fly. |
| | | 1 (8%) | |
|
|
| | Rant time - Unfortunately not as fun as hammer time.
I don't know about other people, but at the end of the meeting I was a little annoyed. I imagine that it was due in part to not yet having eaten, all while Luke sat on his unopened bag of potato chips (my chips actually = my dinner -- SW) My apologies, this was irrelevant to the actual post at hand -- Davesomewhat akin to a more famous parish master. But in addition to this, we were discussing the notion of biweekly deliverables, which personally I would be more for. It was even suggested by Derek that we could still have weekly meetings, while having biweekly deliverables. Personally, I am for this. Isn't this essentially what got agreed to? -- SW It is not what was agreed to. What was agreed to was that we would have deliverables for the 1st and the 8th. This is exactly the same as it has been with the addition of now knowing what our deliverables for the 8th are. This does not imply that we will in the future get deliverables consistently 2 weeks in advance or anything close to it. We also still have weekly deliverables and not BIweekly. So nothing was really changed.
Rae brought up a very important point in that week by week our project velocity has been something to the tune of: Start something new, work and meet to get it done, grind to get it presentable for the customer meeting (which IS the deliverables meeting), come to a halt while we wait to begin again (and receive new deliverables). It is this whole stopping/starting process that is becoming detrimental to our performance. And this is NOT a new issue. It has been something that has coming up consistently at meetings, journals, etc. True, it has come up often, but no one has addressed the real reasons for this: the misalignment between what you're doing vs what the customer needs to have done. Your development process was flawed, so it was going in the wrong direction, creating the rift between yourselves and the customer.
The reason that I feel that biweekly deliverables would be so crucial is that it gives us a chance to realign ourselves (like Luke wants) weekly, while at the same time we can come off of each meeting and know exactly what we need to do for the next week. How exactly are you going to align yourselves with the customer without having some sort of deliverable? How else are you going to prove you are working towards the end goal? Beyond this, we don't face the same problems with redoing code each week, having one to two days of waiting time for deliverables per week, and more pertinent is the problem where we grind to get one deliverable done and then need to worry about another deliverable the next week that had a large disconnect from the previously accomplished deliverable (something which also costs us time). Yes, the latter does happen, and is to some degree unavoidable, but if we know ahead of time a larger group of deliverables (say 2 weeks in advance), we can better organize their structures and plan in general, in advance. To this effect, I do not feel like it is unreasonable to ask for expected deliverables from the customer at least up to two weeks in advance. This is a very good point, though perhaps not exactly as you state it. The issue is really about understanding the deliverables schedule much farther in advance than just one week, even 2 weeks. With such short sightedness, the development process becomes very reactionary, shifting directions all the time as you point out. You need that longer range roadmap to determine where you are--your weekly presentations should be in terms of that timeline. Unfortunately, the lack of that well-defined timeline (until relatively recently) coupled with slipping deliverables and a resistance to bringing the crucial integration piece (the value system) on-line has caused your customer to lose faith in your ability to stay on track. So now, you are additionally burdened with the task of raising yourself out of that confidence hole. Understandably so, although my argument here is that the point was brought up so that we can say to Luke, "Hey - we recognize that this is a serious problem. We have a suggestion as to how to fix it and from our perspective, this will give us a larger boost in productivity, specifically because it also accomplishes the goals that we both want". Those goals being the maintainence of customer contact so that we realign ourselves each week, a clearer roadmap so that we can see where we are going from one week to the next, shorter conversion times, and greater flexibility so that we can really sit down and fix our internal issues and provide better customer relations. Unfortunately there's a lot of writing going into these journals that say "Oh we just need to do A." or "We really need to grind down and do B". But there's a huge separation between saying and doing - and if we don't have the time to sit down and actually DO, actually implement changes (instead of grinding down one path, getting short of time and falling back to old trends - ultimately leaving us where we were from the start).
My annoyance really stems from the fact that, with all this to-do about stepping up and explaining our thoughts as to why we might feel something should be a particular way, we should try exactly this, and be shot down not for having an invalid opinion in and of ourselves, but for not having shown "maturity" when issues prior to and relevant to customer meetings come up (which thus invalidates our opinion). I will admit that we have not shown a desired level of communication or maturity in this respect, but is this not precisely what we were attempting to do at this meeting? To be honest, I feel that the only reason we have deliverables for November 8th is because a) Felipe asked and b) it IS when the site is supposed to go live. Beyond this, I personally feel that we tried to discuss something at the customer meeting that was pertinent to our productivity, and had the issue merely "passed on". Nice riposte.
Before some one questions why I did not bring my frustrations to the table at the meeting, let it be known that I did attempt to. However, there was a large group sitting to my right (not including Rae) that felt their opinions were of greater importance, and thus controlled the larger part of the conversation. I left soon after, since it was 9:00, needed to do homework for other classes, and needed dinner. I apologize that my frustrations were not more expressed in secret asian gestures/expressions/body language, but I am not fluent in them - and the direct translation of this text would look rather humorous, I'm sure.
I would also like to mention that there was a lot of work done between Saturday and Thursday. A LOT. No one should discount how much effort both individually and as a team we all put in, in order to present what we did at the meeting. Speaking for myself, between working with Corey, Kevin, Matt, and Rae to do my part for relationships and having work for other classes (including 2 midterms), I don't feel that having been assigned the presentation on the Friday or Wednesday preceding would have impacted the amount of time per day spent on it. So we can talk about our "delta t" spent daily on different parts of the project, but
a) Given the amount of time, dedication, and scheduling that went into getting what we had, particular criticisms of how it gets done is both without full understanding of the situation as well as callous (Welcome to the real world. Don't ever expect a customer to be sympathetic to your internal hardships--that's not their concern, and should not be. -- SW) I was not talking about Luke and his reactions here. I'm sorry to say, but I was talking about criticisms from your end, which was really the reason why I brought this point up. I don't expect Luke to be sympathetic (though I'm sure he's a sympathetic person), but I had assumed given your manner of dealing with things thus far that you wouldn't have taken such a frontal manner in guiding us here. Not that it wasn't effective, but it wasn't the guidance I expected and I did feel slighted a little.
b) I hope I am not alone in recognizing the coincidence that this particular issue was brought up to better arrange our "delta t"
To conclude, I do not know why the suggestion of having deliverables two weeks in advance (with weekly meetings to realign and showcase later), like Derek suggested, is not a good compromise. It is a good idea, the trick is to propose and implement it in a way that satisifies the customer's needs. Remember that his need is less having exact, precise concrete deliverables but rather to see enough tangible evidence/proof that the project is on track for completion at the necesarry time. -- SW Well the problem stems from that in order to implement it we need cooperation on the customer side. Truth be told, if Luke had just said no and that be the end of it, I would not have been as annoyed - if only because Derek suggested it, Luke stammered and looked to you for help, and from thereon the suggestion was promptly cast aside, never to be picked up again. From my perspective it seemed far too much like a distraction from the conversation at hand, and more like an aide in ignoring a valid option - hence the annoyance.
Subnote: I apologize for any repetitiveness within this section, and most of all I apologize for the sarcasm/frustration that is inherent in my words. It is not my intention to attack or malign anyone or any group of people, but rather express my thoughts on the subject at hand. I recognize that this is not a blog. |
| | | 1 (8%) | |
|
|
| | We had broken code for several times because some people were working on branches.
We are changing the deadline of milestones, but not all of us like the idea of two milestones in a week. I think this will work because we have coding party every Sunday and we always have something done that day.
|
| | | 1 (8%) | |
|
|
| | Afterwards though, when our milestones are completed, we put off testing the project as a whole. Wednesdays are meant to give us some time to fix integration bugs, but people procrastinate. |
| | | 1 (8%) | |
|
|
| | Thursday panic sessions are pretty bad. It always seems like, no matter how well things are going, we will have a Thursday panic session. |
| | | 1 (8%) | |
|
|
| | -There was some confusion about how the search trees were supposed to look due to my missing the end of the relationship meeting last week.
-Everyone "got their working" by the lunch meeting on Thursday, but it wasn't integrated. (Why was code only working by lunch on Thursday if the milestone deadline was Tuesday?) This resulted in a panic after that of "oh shit, its not working!". I was forced to skip the Schlumberger visit on Thursday in order to fix the code. Corey was helping me for a while (and working on it while I was in class from 1-2:20), but he had stuff to do before the meeting. This resulting in me working alone on four groups stuff, and trying to debug other people's code which I didn't understand fully. Dave was there to explain the Relationship end of it, but he had to prepare a presentation for the meeting, so couldn't help except in explanations and little stuff. |
| | | 1 (8%) | |
|
|
Total: 13 |
7. Development Process: Proposals for change--issues addressed and why the change will help.
|
| | I think clarifying exactly what we want as deliverables for the upcoming week early on (as soon as possible after the customer meeting) helps each team to focus on specific goals they need to meet for the upcoming week. Matt did a good job in doing this in class today and we'll see if it makes it easier for each team this week. In theory it seems easy to align deliverables and milestones but it's been hard to do so. Part of it had been due to shifting and changing of teams that occurred recently. I believe that as teams stabilize this will be lessened. Good. I'm glad someone is finally speaking up for the stability of teams, since it seems that all too often the solution has been, "well, things aren't working right, so maybe we'll just switch the teams around!" |
| | | 1 (8%) | |
|
|
| | We need to put people into roles where they have key responsibilities. I trust everyone in the class to do great work, we just need to give everyone a piece of this thing to own. (Just make sure this doesn't involve changing team leaders around yet again, as Chelsea has noted in previous journals.)
We need to come up with a solution to the problem that Sohum is doing most of the testing, and I think this is that we need someone (possibly more than one) to be in charge of testing.
We need to start design earlier so that things are decided before lots of things are dependent on them (which my milestones for this week should address I hope). As a part of this, interfaces should be designed and stubbed, so that we avoid the problem of waiting on interface definition.
We need to work in the main branch whenever possible, so that we avoid all of the tfs craziness and so that we don't live in our own insular group worlds.
We need to get stuff done for milestone deadlines instead of trying to do it thursday afternoon before the customer meeting (I'm as guilty as anyone on this point). We may also change the way milestones are implemented, but I'm actually less sure of this option personally, although I think many in the class disagree.
To me, this section is all about the "what" without any of the "how" behind it. How exactly do you plan on enforcing that all the interfaces are designed and stubbed? How do you plan on making sure people don't procrastinate and do everything right before the deadline? |
| | | 1 (8%) | |
|
|
| | If all of the team leaders start sending regular (nightly?) progress reports to Brad, Brad should compile them and include what he's been doing as well. |
| | | 1 (8%) | |
|
|
| |
- I will just have to do it. It really comes down to that rather than anything else. Remember that dedicated people like yourself don't just "not do things" because of lazyness. There's a reason behind it. For instance, there's always a bit of a barrier to simply reach out to someone. Perhaps it would help if Jeeyun were more pro-active and working with you to figure out what best to delegate to her? -- SW
- We have decided on a no-branching strategy, or at least no-branching for anything that uses external interfaces. Having everyone work on the main branch should help us avoid such problems in the future. In terms of variant/invariant divisions, on what side do interfaces fall? What happens when to a system when a supposedly invariant piece is changed? Is your "only work on the main branch" solution really just a band-aid over a fundamentally flawed process? -- SW
- I think we are just getting a little stressed because of work from other classes also taking their toll. These situations were resolved quickly so hopefully they shouldn't be too much of a problem.
|
| | | 1 (8%) | |
|
|
| | I know this may be too much, but maybe an agenda would help? Also, if we make an effort to make as much use of the short 45 minutes, it would be better as well.
I tried (late) to make an effort to get involved with the rest of the team, and I plan to continue that effort this week. Working on documentation helps, since I can see the updates that people have made or the ideas that they have and how they have been molded.
I think the Sunday/Thursday milestone will help the rush that we had this week. We should create a "static" build off the Sunday milestones and keep working on Thursday milestones, and add the ones that won't break the system. |
| | | 1 (8%) | |
|
|
| | The old work cycle is flawed - adopt a new work cycle. There have been big problems with our milestones being set on Tuesday, and with trying to sync them with the customer meeting deliverables.
I pushed hard for change of milestones from tuesday to a sunday and thursday model (wednesday might be better, but we'll adjust as we go). I hope that this: 1) will help us to stagger milestones so that things that need to be in place for other teams can be done by sunday, and 2) will sync us up to deliverables by allowing new milestones to be assigned on Fridays right when we have the new deliverables list. Great! The staff hasn't been saying this all semester or anything ;-P There are some reservations in several places, but I think it is imperative that we try something new. The old system was not working (evidenced by what has been happening on wednesdays and thursdays to get ready for the customer meeting), so we need to adapt, and quickly. A sunday-wednesday system has worked very well for Yuan and Felipe, and I have faith in their recommendation. |
| | | 1 (8%) | |
|
|
| |
- There was a general agreement to stop branching in class. This will hopefully solve the problems that arise when merging projects back into the main branch, such as unintentionally rolling back changes and bug fixes. Hopefully seems to be a word that always comes back to bite 410 students. This also means we're more aware of what other teams are working on. For example, some teams have had methods/interfaces that other teams needed, but were on their own branch, so we were unaware of them. Does it occur to anyone that your interface development process, besides being too late in the cycle, is also backwards? The interface should be dictated by those that use it, not those that supply it. An interface serves the needs of it users. The back-end of the interface should be configured to supply those needs. -- SW
- It was eventually decided that the problem with our workflow not being in sync with the customer meeting every week. Ideally, our goals should be exactly aligned with the customer meeting, so that the things he needs to see are the same things we need to prove to ourselves. To achieve this is a balance of reasonable milestones and deliverables as well as an efficient way of working towards those goals. Our coding sessions help with this as they are a way of having everybody in place to solve problems that we don't have time for in class. Also, frequent emails informing others about progress and impediments allows others to be kept up to date about what needs to be done and what obstacles we have to tackle as a team.
|
| | | 1 (8%) | |
|
|
| | - For the issue with the backend and Rae not getting their stuff done in time, the solution is simple: Get your stuff done in time. When someone is depending on you for something, and you put it off, for whatever reason, you are giving them less time to do what they need to. I don't care if you need to drop everything and do it. If your checkin busted the tree, you fix it. If there's an issue with your interface, you resolve it. If you don't, then you're letting down the people that are relying on you, and they're not going to be happy, much less able to get their work done. With that said, I realize that sometimes it's difficult for this to happen; we don't all work in an office building where we can just walk down the hall to find the person we need. Use email, or phone is even better. And if someone needs you to do or fix something urgently, then do your best to make it a priority. In most cases, if you broke something, it shouldn't take too long to fix it; just don't put it off. I would hope that no less is expected of myself.
- Regarding the backend's design, Brad, I think you may have been overstepping your bounds there. You need to refrain from getting an idea in your head and forgetting to listen to us little people. I think that I have the most experience designing and working with databases of anyone on the team, and I really hope that my views were not taken for granted. I can assure you that I was not exaggerating in my speech about the drawbacks of the design you were pushing on the rest of us. I also don't recall anyone else standing up for the design. Yes, it's something that looks great on paper, and might be seen in a realm of research, but in regards to practicality, you need to go with what's tried and true. We've heard the phrase "don't reinvent the wheel" thrown around alot, but you should also be wary of "inventing the wheel". This project may be new and in some ways groundbreaking, but we certainly shouldn't invent an entirely new way to store our data. I talked to Aaron after the meeting on Sunday, and he seemed to be pretty much inline with my thinking. You should ask questions rather than give answers, and trust your teams and team leaders to know what's best with designs and code they work on every day. Good point, and hopefully one that Brad has taken to heart.
- Kevin, I shouldn't have to tell you to do your work. What's important to you is not necessarily what's important to me, Brad, or the customer. I realize that the value system report wasn't going to be great, and would be pretty much superficial in content, but I was just hoping to see *something*, and I think the customer was as well. The fact that you absolutely failed to deliver, and then refused to go back to your room and get the document even at my suggestion, disappoints me greatly. You have great ideas and you should think highly of your ability to contribute, and you should realize that trying is always better than giving up. I've already talked with you about this, but I figured I should document some of my thoughts about this here. I told you during the meeting that I could talk about the value system without the documentation I wrote. This has a lot to do with the fact that at the time, our understanding of the value system was still very abstract, and by no means even a complete overall understanding. Both you and I acknowledged that writing documentation on a nonexistent system was an almost futile effort, but I was prepared, if needed to present our findings so far on the matter. I am open to whatever challenging tasks you may assign, but bear in mind that there should be clear and well defined objectives if you want me to get anything done. --Kevin
- For tasks that are assigned at the last minute, or are never clearly stated: Brad, please *please* keep the team milestones page updated. If our milestones change, change them on the page. Yes, please, Brad. Not only does this keep the entire team up to date, but it helps the staff as well! Otherwise, it's difficult to know exactly what you expect of us, and I feel like we shouldn't have to go hunting. For next week, if you ask for something and it's not on that list, I can't guarantee we'll be able to deliver it. Similarily, if these are things coming from the customer at the last minute, and you think they're probably too difficult for us to do in the time allotted, you need to stand up for us and tell this to the customer, because you're the person he'll listen to. You alone have the best view on what everyone is doing and how the project is going, and if you think we already have a lot of work to do, then you should try and let the customer know that we won't be able to finish all of his requested deliverables. Also, don't promise things in advance that you're not at least 90% sure we'll be able to deliver. |
| | | 1 (8%) | |
|
|
| | I really don't know at this point. It seems like our proposals are irrelevant and get in the way of getting our job done. So I suppose we should focus on that instead and consider the issue resolved. Even if your "proposals are irrelevant" in your mind, they might not be to others. And if an issue isn't resolved, you probably shouldn't consider it so. |
| | | 1 (8%) | |
|
|
| | Try to not work on branches, and keep all the files updated as we work. What happens if people don't keep their files updated or continue to work on branches? You should probably have a contingency plan to make sure the group isn't frantically trying to merge a week's worth of code right before the customer meeting.
We could try it first. We don't like Tuesday milestone but we had it for five weeks. And if something is really important and other teams are relying on it, we need to get it done by Sunday. Yes. Even if people don't like the idea of two milestones, one milestone was clearly not working in terms of getting work to other teams in enough time for anything to happen, as evidenced by Corey's journal. |
| | | 1 (8%) | |
|
|
| | We're considering having staggered milestones perhaps, as a way to have teams that are coding dependencies to finish first and have teams that build on those then work with that code. I think this would work.
How does this address the issue of lack of testing? -- SW
I agree with Dr. Wong here. This is a solution to a different issue entirely--that of people not getting work done on time. This is not mentioned at all in the sections above (in fact, you said "once the milestones are done," not "the milestones are not getting done." |
| | | 1 (8%) | |
|
|
| | The best I can come up with is to move the time for having a complete demo to much earlier, like Tuesday. However, we probably wouldn't get enough done for the demo meeting. So, frankly, I don't have any good ideas right now. Then again, I'm feeling kind of sick today, so I'm not on the ball right now. Check out some of your teammates' journals for suggestions. |
| | | 1 (8%) | |
|
|
| | -The confusion was solved between Dave calling me, and the code-party last Sunday.
-In the future, the class going do something directly before the customer meeting is a bad idea in general. Also, and more importantly, we need to learn to integrate sooner. We are trying to deal with this sort of thing with "Sunday-Thursday" or "Sunday-Wednesday" milestones. This allows for the stuff that relies on something else to be done by Sunday, and thus when the "on-top" part gets done, part of their milestone is integration...so rather than just saying "do your part by XX", we can say "have this working with YY by XX". This sounds much better than the current setup. |
| | | 1 (8%) | |
|
|
Total: 13 |
8. Peer review: Positive or negative feedback for other class members
|
| | This week I'm breaking the trend, and I'm only going to say a couple of things (ok so it became a bit more than I intended, but whatever)
Aaron - you took over the research on the triple-store stuff in a serious way and did a great job with it
Felipe - you are speaking up more often, but you should do it more; you say a lot of really useful things and you are a very good persuader
Matt - I hope I'm doing a better job of utilizing your abilities, and thanks for being filling where I lack.
Sohum - you are working really hard, and I'm going to try to take some of the testing and integration onus off of you (even though you are REALLY good at it) because I know you're going to have a ton of work soon.
Yuan - great job with your demo, keep it up: we'll need to use your JavaScript skillz soon
Corey, Rae - thanks for the patience, manifested in totally different ways
Derek - you write great code, thanks for sharing your wisdom and talent |
| | | 1 (20%) | |
|
|
| | I was frankly quite stunned at the WYSIWYG text editor that Yuan presented. I know that some of that magic came from code from the internet, but I was impressed. And, since I was sitting at the end of the table, I could see everyone's reaction to it, and people who had never seen it before (especially Luke) were amazed as she kept on demonstrating more and more things it could do.
Hubert and Matt did excellent work this week in bringing the backend's relationship model online.
Everything else worked very well for the customer meeting. Great work, everyone. |
| | | 1 (20%) | |
|
|
| | Dave wins most improved for the week. Your performance from last Friday forward has been phenomenal. You are putting solid backing behind the promise you made to Dr. Wong in that journal.
Felipe and Sohum are my heroes for the week. Felipe for doing the documentation work, and also really making his presence known in the team, especially in the last couple days. Brad made some comments about that in his journal. And Sohum for getting the trust network on the profile page, and also for coming up with a cool logo and making the themes work. Not only did I like the logo, but the really great thing is that Luke seems to like it a lot as well.
I was really pleased with Yuan's presentation. Luke was very impressed, and that always helps customer meetings go smoothly. I think the embedded content capability is fantastic. I know you were nervous beforehand, but I could not tell during the meeting. You handled Luke's questions well, and also the points where people interrupted.
I also thought Derek did well, especially with some parts of search not quite showable yet, and with Luke putting him on the "hot seat."
I'm looking forward to seeing Jee Yun get Identity Verification going. I think she is a perfect choice for this task.
I had a great discussion with Corey after class today about trust and authority, and I think he should give a presentation on that at the next customer meeting.
Thanks to all the work of Rae and Corey and Sohum and others who got things working on thursday. I was very pleased with the demo, and I think you all deserve a vacation (not that any of us will get one).
I'm very happy Aaron has figured out a lot of stuff about the RDF/SPARQL and how to arrange the database - most of this stuff is beyond me. He is taking ownership of this system which is exactly what needed to happen.
Brad's energy and enthusiasm is what keeps us going. Keep inspiring us! |
| | | 1 (20%) | |
|
|
| | Dave, you gave a great presentation on Thursday. I only wish you could have helped out the relationships team more in the hours before! |
| | | 1 (20%) | |
|
|
| | I'll follow the group in saying that I was extremely impressed with the work that Yuan got accomplished. It was rather amazing.
I also want to give special acclaim to the team as a whole. What we pulled together was nothing short of a miracle. |
| | | 1 (20%) | |
|
|
Total: 5 |
9. Additional Comments
|
| | A lot of really good and important insights and realizations here! -- SW |
| | | 1 (11%) | |
|
|
| | No fun Friday. Matt sad.
Great points Matt--is everyone listening?
Even if you were sad, you still wrote a great and insightful journal. |
| | | 1 (11%) | |
|
|
| | Fun Friday!
Make sure that you delve a little deeper into your solutions and that you don't gloss over the details in your milestone section as much. |
| | | 1 (11%) | |
|
|
| | I realize that this journal is quite negative, toward a number of people. Please know that I like and respect you all, and I hope we can all learn from these experiences. If you have any complaints about me, bring them on, because I can take it.
Love Corey
A lot of very important things said that really needed to be said. I hope that everyone takes what is written here in the Corey's spirit of learning and understanding. -- SW |
| | | 1 (11%) | |
|
|
| |
While it's okay to present your frustrations in a journal, you will lose points for focusing exclusively on one section. --Chelsea |
| | | 1 (11%) | |
|
|
| | A little more meat on development process issues would be best. |
| | | 1 (11%) | |
|
|
| | A rather sparse journal. Try being more detailed in your development sections and solve the problems that you lay out. |
| | | 1 (11%) | |
|
|
| | Late; -5pts. |
| | | 1 (11%) | |
|
|
| | Super late, >.< I forgot until Derek mentioned it to me 30 minutes ago...
Good journal. Late; -20pts. |
| | | 1 (11%) | |
|
|
Total: 9 |
|
|
|
|
|
|