Reports/week 5

From Riley Consulting Wiki
Jump to: navigation, search

Report for Mar 10 - 14

Summary:
    Many of the points I brought up last week were hearkened to this week, and I would like to believe that is was because of that that the Storm team had its best week in a month. Specifically we spent some time documenting the design for the C++ module at the heart of Storm. We also relaxed the week-long iteration cycle, which I have been pushing for from the beginning. There is hope that we will be able to finish our goal for the quarter next week, which is wonderfully exciting.
Details:
    We made a design doc this week. It still is not as formal as would have liked, the features are not nicely numbered or grouped together, but the interfaces were laid out, failure conditions for each function were established and the borders in the code were well defined. As a direct result of this, I was able to build one implementation of an interface while Brandon built another. We were able to work separately and yet, for the first time in the whole project, both pieces worked perfectly when put together. We were also able to write much better unit tests for both of our classes since a great deal of ambiguity had been removed. Yet another advantage that came from the design was that I was able to build a piece that depended on something that didn't exist yet. However, I was able to stub out the missing classes, get the class I was working on to pass my unit tests, and then by the end of the week hook it up and take it live with little hassle. The process wasn't totally smooth, as I realized once I built the UI portion of my piece that I needed some data we had not thought about. But I was able to change the design doc, inform Brandon about the change, and things went together.
    Since the beginning of the Storm project, we have been trying to follow a strict, weekly iteration schedule. All of the details are in my Iteration Review/Planning Meeting proposal, but I will summarize here. My project manager wanted our team to release whatever code we had ready (meaning unit-tested and code-reviewed) to QA on Wednesday. This meant that the code reviews would take a few hours out of the morning. Wednesdays are already when we have our company-wide developer meetings, so reasonably the code isn't getting released until mid-afternoon. At that point we can start to work on the next tasks we have assigned, but there are expected to be constant interruptions as QA comes back with bugs for us to fix. Thursday was to be set aside to be a whole day of going through QA rounds, in part because I don't work full days then. Finally Fridays were to be the team meetings where we reviewed the last week and planned the next one. Fridays are also the days I have given to me to talk to Brandon and anyone else I need to in order to fulfill my consulting responsibilities for this class. If you're counting, that leaves Monday, Tuesday, and slivers of Thursday and Friday to actually write code. This struck me as overly rigid and forced, to the point where the developers were not getting enough time to actually develop. I brought this up, but there was resistance to it from management even above my project manager. Week-long iterations is an "Agile" thing, and we are agile, dangit!! The fact is though, when we are programming a server to route thousands of calls, that looks far more like systems programming than web-app development. Those intricate systems take more time. I have found that they take a little bit of a waterfall approach. Significant time needs to be given to detailed design and planning, code needs to match up to the specs, and tests can confirm that you did indeed build what you meant to. All of that together means that two and a half days of dev time are simply not enough to get done what needs to be gotten done. So we have created a kind of hybrid development process. We have "Systems" iterations. These are longer than the other other kind, the "Web" iterations. We expect systems iterations to take around 3 weeks, whereas web iterations should fit into the 1 week iterations we had before. Interestingly, this taxonomy proved to be far more important than I thought to our managers. It allowed them to understand that we were in the middle of things that were hard to see, and that they wouldn't get a demo of our new stuff for a few weeks. By giving that a label and showing that it was part of the plan, they relaxed a lot and as such we felt some of the pressure get relieved. This is a lesson I did not expect to learn, it matters what you call things, and having a name for everything puts people at ease. It is something we have not talked about in class, but something I have seen be crucially important. Every problem that has arisen can be traced back to a communication error. My managers are wonderful, they just don't use words the same way that I do. So when we can use or create term that disambiguate the ideas, I have found that it is not hard to get people on the same page. It's all a matter of communicating what is going on. As an example, we pulled our CFO into my office the other day while Brandon was working in there. Our CFO is invested in the status of our project since he wants to be able to do some forecasting. He is also in charge of the larger company goal that our product is a sub-goal of. The purpose of this discussion was to inform him that there were some features that were going to have to get cut in order to meet our deadline. We laid out three that we believed needed to be cut. He wanted to know which one was the hardest. So we ranked them. From our perspective, this conversation was entirely about information. There were no decisions to be made, we were just telling him that these three things needed to be cut, and if we were really lucky we might get one of them done. By the end of the conversation, he though we were asking which one should be cut, and so when he told us to only cut the hardest one things got a little bit heated. We felt like he hadn't been listening, and he felt like we hadn't been clear. All of this could have been avoided if less ambiguous terms had been used. So that is the large lesson for the week. There is value in the terms you set, and doing it right can bring management and development into rare-blissful harmony.