Second-half kick off
An individual project at University feels very much like managing a football club for a season. Getting points on the board each week is important, and there are a dozen different distractions which have bearing, but the most important thing is consistent good results and by the end of May the result will be fairly clear if not final. This does not apply to the uber-genius class of people who wake up one day and have it done within a month. I risk nothing by stating that I’m not a member of that particular club, so it’s very much my responsibility to grind out the work.
The plan remains loosely to design, implement and evaluate a prototype. Talking to my fellow students, it is clear that the pattern varies from project to project. Some will start on design and implementation from day one, whilst others will spend a great deal of time with the research. I know at least one whose implementation is complete for the most part. However mine is circling the design and implementation whilst the survey is out in the wild. Essentially, I am focusing on work that will have to go into the application. This means avoiding doing any work on requirements which may not be included due to time constraints or are dependent on user feedback in the survey.
I have always tended to focus on getting the job done. This could be a historic fallback to my days of rapid application development where the paperwork could wait. However, I’m trying to make a concerted effort to balance the paperwork and the implementation. I spend a couple of hours work on this blog to keep in the habit of writing and thinking about the project direction. The biggest problem that exists with writing up a project is the inability to remember the reasons behind the little choices that eventually have a big impact on the overall result.
One little piece of reasoning has been how to structure the data for visual elements on screen and how these can be searched. It was decided that visual entities are stored in a B-Tree structure which using bounding rectangles instead of values, otherwise known as an R-Tree. Developing my own library for such a task seemed to be a waste of valuable time and Java libraries existed for such a purpose. I found two good examples, but it was difficult to determine which was the most appropriate to use and what impact that would have on the overall design. The focus seems to be on the ability to not only implement, but adequately explain and justify choices. I doubt I’d remember all the little decisions like this when it comes to project Viva.