View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Building the Codebase - Ben Litowitz

Tackling the Codebase

2340 Individual Case Report

Ben Litowitz

Team Shake

Tackling the Codebase

Part 1. Design is Important

            By the end of the project, the flaws and perfections in our design became amplified: adding new random events was very easy, but attaching our backend data structures to a web front-end was tricky because of coupling with some GUI elements (most problematically Dialog Boxes).

It would have been difficult in the beginning to predict the outcome of each decision, but if we had adhered to certain principles of design, such as never allowing the model to be directly aware of the view, things would have gone much smoother.

Specifically, I think designing the GUI prior to, or alongside of, the UML diagram would have been effective. In this way we could have more easily assessed what information our backend needed to provide for our front and in what format. Being aware of how the GUI would be coupled to the model by AspectAdaptors also would have made it much easier up front to know what needed to unhooked before we could BOSS and save our data.


Part 2. Don’t Skimp on the Basics

            Some classes (especially information holders) may be easier to code than others. However, just because these classes are easier doesn’t mean they should be rushed. In fact, those classes which are easier to make should be more fully featured than others because it is very clear what’s expected of them. These classes are often the ones being displayed on your GUI, so things like printString functions and other topical things are necessities. When it came to the end of the project, lots of little things slowed progress because we were forced to go back and augment our base classes. As mentioned above, designing the GUI concurrently with the backend may have made us more aware of these issues.


Part 3. Division of Labor

            One of the things our group did especially well was manage what needed to be done. We started with five members, quickly dropped to four, and then lost another as he fell off the radar. Our initially grand design plans now seemed a bit imposing for the remaining three individuals. However, by simply creating a list of all the classes that needed to be written and having each person grab the next one from the list whenever they were finished, everybody was always busy and nobody was ever waiting for someone else.

            Throughout the semester, each group member had many responsibilities for other classes in addition to this one, so there were times where one member couldn’t accomplish as much work for the project as was necessary. In this case, the other two members picked up the slack, because we hadn’t decided up front that these classes were specifically for this person.

            Additionally, by leaving some of the auxiliary classes off until the end (when we realized that our group wouldn’t be able to produce them) allowed us to create a finished working product, even if it didn’t have all the bells and whistles that we’d initially hoped to implement. In the end we were pleased with what we’d been able to accomplish by being as efficient as possible with the resources (both time and man-power) available.

Links to this Page