Group Project Final Retrospective - BCDross/IST320-group-project GitHub Wiki

Team Burn Builder

Professor Phil Duncan - Bellevue College

ISIT 320

12/13/2020

Problem Statement

Insufficient planning and time management presented a series of setbacks to the project, and prevented a hosted solution from materializing.

What Happened

Looking back on this project, We had several issues that seemed to be easily fixed at first, but turned out to be rather difficult to surmount. When we first started, we truly thought we were keeping it simple as we were laying out what we wanted the app to do: let a user log in, be able to use the API to call cards for the user to browse and save in order to create a deck out of them. Simple as that.

First problem:

The API was not giving us usable data. When we looked at the data given from the API, it turned out that whenever we called the API, the data was given in a single JSON object of JSON Objects rather than broken up into make JSON objects, which was frustrating and took up a lot of time to figure out how to do because we were expecting data to be easily deserialized into the individual cards and card sets. By the time we were able to figure it out, we found out that calls to the API would only let us get data for about 100 cards at a time. This wasn’t a problem in and of itself, just another example of a limitation that was missed in the initial investigation and planning stages. But we still were confident in ourselves because we thought that now we finished this part, all we needed to do was populate our database and figure out how to allow the user to log in, browse the cards and create a deck out of them.

Second Problem:

We made the design decision to go with a data driven app using Entity Core Framework. So we needed some type of datastore for the application to work. Our database of choice was MS SQL Server as we were all experienced with it and thought with Azure it would be the easiest of the databases to get working. During the initial planning sessions, we did not investigate the possible costs for setting up the server and database to be able to run the app. The hosting cost on Azure is minimal and was well within the 100 dollars available per account, but unfortunately the MS SQL server was much more expensive than we had thought at nearly 300 dollars. By the time we discovered this we had just under two weeks until our presentation. Khang and Darren took it upon themselves to see if they could get a replacement datastore system in place in the code, but unfortunately while they both worked on separate options both of them came up to a point where they could not get the system to integrate and work with the app without more time to investigate and get a working system.

Third Issue:

Bad time management leading to not enough testing. With the experience we all have had with PROG123, we had roughly an idea of the size and complexity of the site that we were going to build, as well as a pseudo template that we can work from in the form of the course project from PROG123. We tried to adhere to the tenant of “Keep it simple.” And in the beginning, when we were planning the application and when we started to build it, we were able to get things built very fast but didn’t continue to develop once we hit our weekly goals. We would stop until the next week. This proved to lead to two things, overconfidence and untested code. Since we were able to complete things so quickly we moved to other portions quickly and it worked the way we expected once meant that we could move on. We kept the portions of the app small and thought we did sufficient testing. An example of this is when we started to attempt to do full testing with creating a new empty deck, we discovered that the deck is not saving the userid from the Session to the deck. When debugging this, we realized that the User was successfully logging in and returning the id and we were saving the key “uID” to the session but we were not saving the userid value, so when we would go to creating a deck it was always saving with a user id of 0. This took several hours to identify and fix, where if we were doing more thorough testing and debugging of features while we are going probably would have been caught in development and we could have saved most if not all of that time.

Fourth Issue:

Not enough planning into the later features. In an effort to keep things simple, we got complacent in thinking through the more advanced features, especially when we started coding them. One instance is where we were attempting to add a card to a deck. We decided on an MVC app, and with this we needed to know how to use multiple models in a view in order to properly create, display, and access multiple model objects. The first instance of this was attempting to set up the account page and display a list of the decks that user had created. We were able to successfully integrate having multiple models into one view, but it took a lot of time to research and by this point, we had only a couple of days to the deadline. Again we were able to complete the account page, but we were not able to complete the feature to add a card to a deck, which is a central feature to the app, being able to build a deck.

Resolving These Issues

Complete and thorough investigation and planning:

Almost all of our issues could have been mostly, or even completely, avoided with more thorough investigation and planning. More careful reading of the API documentation would have exposed the 100 card limit, and the formatting of the return sets as a single element of json packages. This would have started research earlier into how to handle the deserialization. If we looked and investigated the hosting much sooner we would have seen the cost involved and maybe decided to go a different route. Thinking through the features and the functional requirements of each feature.

Better Time Management:

Time management was something that went badly for us in two opposing ways, in the beginning we had the time to do things and chose not to because of other stresses(other classes projects) instead pushing it off later because we thought it would be easy and we had more than enough time. While near the end of the project, we were scrambling with the realization that we did not have enough time to complete the project.

Proposed Steps To Resolution Of The Issues

The biggest technical fix at this point is to have the database be a different type of SQL database. Such as PostgreSQL, and abandoning the entity core framework in place of SQL database scripts to create the database and tables. Or leveraging a no-sql solution such as mongodb, to allow file based datastores to operate.

The biggest overall fix for the development issues of the app aside from the database is to return to planning the features and getting all the details down on paper for the expected capabilities of the feature and the app as a whole.

Implementation plans

Due to the amount of work already done and the intertwined dependency on entity framework in the app at this point. We believe replacing MS SQL Server with another SQL database type is best. There are several measures that are free and have drop in nuget packages with minor code changes to support the new database type. PostgreSQL is the suggested replacement at this time due to cost reduction, ease of installation and operation, and simplicity of the database system operations.

Continued development of the remaining incomplete features is also a priority, as they are near completion and will present a fully working app.

Future goals

First Goal:

Not repeat the mistakes that we have done during this time. Fully think through the remaining features before beginning to code. Doesn’t not need to be an excessive amount of planning or detail but does need to be enough of a functional engineering completed for the feature so that minimal engineering will need to be done while coding and implementing the feature.

Second Goal:

Add additional intermediate functionality features, Card Search and Deck Search. These are features that most people expect a similar site to have. As well as fully integrating the API calls into the search functionality to be able to have the search complete in the database first and if not found to do a call to the API to attempt to find the new card and update the database with the new card info.

Third Goal:

To add more advanced features to the base and intermediate features. Deck statistics, and card suggestions based on those statistics. These are multi-tiered features that will require a base level of functionality and then be improved and added to over time. Add a full card inventory system, with a card library that you can add the cards and the number of cards you have to that will also link you to which decks have this card in them already. This will allow users to be able to track their cards much easier.