Ken Vader

CST-438
Professor David Wisneski
12/16/16
Final Project Report

For our team project, we chose to make a version of Rock, Paper, Scissors

that would have game elements beyond just the initial selection of rock, paper, or

scissors. We wanted to have different game modes that would add more depth to

the gameplay without requiring a large time investment in animation development.

We considered many different game types, including a 2-player mode, a player vs.

computer mode with health bars, best 2 out of 3, and a story mode that required a

certain number of wins to move to the next part of the story. Some of these ideas

required more time than we have available to implement them, so we chose to start

with the player vs. computer with health bars as a starting point and see how much

we could get added in after that. We will also be including some statistic tracking,

both for the current session and across multiple sessions. Our project will be using a

SQL database to store the statistics between sessions, and we will use JPA to handle

interaction with our database.

Code quality is a way of measuring many aspects of a code base. How easy

the code is to read, how well named the variables, classes, and methods are, the

complexity of the code and the comments to explain those sections, and adhering

to a design pattern are all factors in making good quality code. Creating good

quality code results in an application that is stable, secure, and easy to use. While

there will always be differences of opinion on the specifics of formatting code, good

quality code always sticks to a consistent format. Avoiding spaghetti code and

adhering to well defined design patterns also contributes to good quality code. Code

should be self-documenting, but with comments where they are needed to explain
more obtuse sections. Teams should strive for their code to be readable and

understandable by any new programmer who reads through the source.

On our project, we utilized several tools and employed some best practices to

help us create good quality code. We made use of a Github repository to allow us to

work on a single version of the project with no confusion as to what the latest

version is. We also took advantage of Pivotal Tracker to help us organize our

workflow. Pivotal allowed us to brainstorm and prioritize in the same tool, while also

giving us a place to see who was currently working on what. Of all the new tools

that we were exposed to in this course, Pivotal was by far the most useful and

easiest to use. Our team employed code reviews to ensure that any code we

produced was not only bug free, but also easily readable. While writing code, we

wrote unit tests which were also committed to the Github repository to allow for

regression testing. Our project was a simple one, so keeping the code clean and

simple was a big part of our mission. Keeping our code base stable by thoroughly

testing changes and additions also contributed to our code quality.

Team velocity is a way to measure how much work a team can get done in a

given period of time. A numerical value is assigned to tasks based on an estimate of

how much time it should take to complete said task. At the end of an iteration, the

numerical values are summed, resulting in that iterations velocity. These velocity

values can then be used to plan future iterations, make more accurate estimates on

when work will be completed, and estimate overall project completion date. On our

project, it was helpful to see how quick work was being done over a week, allowing

us to prioritize features more efficiently with the time available to us.

This project makes use of the MVC pattern by keeping all of the logic in the

.java servlet files, the view is taken care of in the. jsp files, and the model is handled
by the SQL server. We did not end up using JPA to handle the database objects and

communication, but rather wrote some simple SQL statements into some methods

that we could re-use. The methods handle database connections, reading to the

database, and writing to the database. Keeping our design consistent with this

pattern helped prevent the spread of spaghetti code and made refactoring easier.

As we progressed through each iteration, by using the MVC pattern it was also much

clearer where to add certain components when we wanted to add a feature or alter

the design. Had there been a longer timeline to plan prior to beginning the project,

we may have elected to use additional patterns. However, at this time MVC is the

only pattern we are using.

If given the opportunity to begin again, one of the things our team would

change would be the priority we put on getting the database section running. In

hindsight, it would have made more sense to start from a simple database web

application and expand out from there. In the end, it will not affect the final product,

but it would have simplified some parts of the development process. Another area

we could improve on is planning the weekly sprints more concretely. We used

Pivotal and had our stories and tasks entered, but there was not enough ownership

of tasks throughout the team. It would have made more sense to have us each

commit to at least one actionable code item per sprint, and then pick up more if we

finished before the sprint was over.

Communication throughout the project was done mostly through Google

Hangout chat sessions and a little bit of email. We did speak throughout the week,

which was great. Everyone on the team was quick to respond to messages, which

made working through issues much easier. We did not have enough formal team

meetings, as most of our communication came in bursts throughout an iteration.

The formal weekly meetings might have helped solidify everyones understanding of

their part in the project and helped keep everyone on the same page. Doing this via

a video conference would also lead to more ownership and accountability regarding

sprint iteration tasks.

The communication issues that we did have, mostly in the form of no formal

meetings, likely caused a disconnect in the expectations of what was required from

each team member. With that in mind, if we were to do this project again, it would

make sense that the first order of business would be to agree on a set meeting

schedule for the life of the assignment. We could have planned twice weekly video

conference meetings, scheduled to only last 15 minutes, where we would have the

opportunity to talk about what we are working on and ask questions about what

others are working on. This would facilitate adhering to the Agile methodologies

that we learned during this course and also make it possible to have concrete

ownership of tasks. It would also be a forum for team members to talk about where

they are having difficulties and ask for help, or to talk about their successes and

explain their design decisions.

The requirements of our project shifted over time, as we considered new

features or alternate design possibilities. It may have been possible to accomplish

some of this with a Waterfall methodology, but it would have required a significant

amount of time to plan and many meetings for us to settle on the design. In the

end, the Agile methodology was the right choice for this project, as it allowed the

design to evolve as we saw working prototypes and made decisions based on that

rather than theory. There was not anywhere in this project that a Formal process

would have been needed, and it likely would have just slowed things down and

gotten in the way of the development cycle. The needs of this project are such that
a Formal methodology would have been overkill. Perhaps, in the future, if we had

tried to something more, perhaps have financial transactions involved, a Formal

process would make sense. When dealing with money, it would seem prudent to

make sure there are no errors anywhere in your code that could cause severe

financial distress to a customer.

We attempted to write the code in a self-documenting fashion as much as

possible and then use comments in places where the intent might not be as clear.

There were only a couple of places where we felt comments were strictly necessary.

The code is well organized and easy to read, with meaningful names for the

variables, methods, and classes. A new programmer would be able to familiarize

themselves with the code in short order and there would be little confusion on how

the project fits together.

We have so far needed to refactor the way we handle single sessions and the

way we handle a game loop. We initially had one class that was handling holding

the session stats and a game loop inside of the post method of our Java servlet

file. We have decided to shift to a class to hold the stats, a class to handle the

players playing, and keep our game loop where it is but make use of the two

refactored classes. This will make it easier to add other game modes, as well,

because the player and stat keeping classes will be independent of each other and

independent of the game.

This project has been a great learning experience. It provided the opportunity

to get my hands on some backend programming and gave me exposure to new

technologies that I may not have looked into on my own. I plan to use the project

going forward as a testing environment to get more familiar with Java and J2EE. The
exposure to new frameworks and design concepts will transfer to other languages

well, should I decide not to pursue Java as a career path.