Prototype and Feature Additions

I believe we have a working prototype of the main diagnostic tree traversal functionality. This is very exciting because it means we have a working product. We can now start adding tertiary features to increase the user experience but can be a little more confident knowing if a feature doesn't work as well as we'd like, it is less critical to the overall process and becomes more of a "sum of the parts" type design. We also can now add some meat to the bare bones aspect of our database and really flesh out everything.

Iterative Design

Having spent some time recently perusing different design philosophies and trying to figure out which one our group has most closely identified with, I think that we have been taking an approach that is closest to the Iterative Design pattern. That is, we are consistently looping through a cycle of development, testing, feedback, fixing, development.

So far I think it has been working out very well for us generally. It does seem to naturally integrate well with the weekly client meeting and action item structure that the class entails. It may be an interesting idea to experiment with other types of design philosophies, but I am hesitant to change our workflow with the stakes so high.

String Matching Approaches

The text entry box at the beginning of our user experience (UX) is going to be one of the next aspects of Mechanapp to be tackled by the group, and we have some choices as to how to go about it. I am going to outline some of those choices and my thoughts on them below.

Naive String Matching:
We could chose to do a very simple naive string matching, looking for year, make, model, and one of our described symptom. Any parts that are exactly matched are populated and the rest is discarded and the user is prompted to fill in the missing pieces.
This is simple and would be easy to implement but lacks enough functionality in my opinion. It may however, be a good place to start.

"Hint" matching:
One other idea that has been proposed is to have a database object that represents something called "Hints". What this would do is map multiple strings to single symptoms. For instance, the symptom "engine will not start" is a formal symptom, but that sentiment could be expressed in many ways. So using a database object we would have many examples of strings that all result in a reference to the formal symptom. For example strings like "won't start", "isn't turning over", and "engine seems broken" would all map to the formal symptom "engine will not start". We would then do string matching on all the hints.
This is functionally just an extension to the naive string matching approach. I believe it has the same advantages and disadvantages and is just a natural extension of the first. As such, I think it would be a good second step.

More complicated things like String Edit Distance:
One interesting idea is to make it more complicated but smarter and have the strings not need to match exactly. This would allow for smart handling of typos, and potentially phrasing that we haven't anticipated but can be mapped to symptoms we have described. One way to do this would be to use an algorithm like string edit distance.
I think this is a great idea. Additionally, I think I would be well suited personally to implement it. While I've never implemented string edit distance, I have as part of my research implemented a graph edit distance algorithm that I designed which is very similar.
String edit distance would allow our search to be much smarter, but still be relatively easy to implement (as well as give me another task that I am actively excited about implementing).

Text Entry Box Functionality

The group envisions the text entry box at the start of the user experience (UX) as being a way to populate the drop down fields of year, make, model, and symptom. So the user would enter something like "My 2002 Honda Civic won't start", and the appropriate boxes will be filled.

This presents us with some challenges though. How complicated do we want this feature to be? We have learned from Professor Ackley that being one of the first and physically largest parts of the UX it is drawing a lot of attention, and subsequently should be pretty impressive in it's own right.

While we want to avoid having to write a complex search engine, we also want it to have decent functionality. This provides us a continuum of functionality on which we need to place a goal--from exceptionally smart and intuitive to less functional but easy to implement. In the near future I will discuss some ideas for adding this functionality, and maybe with thought to actual implementation this decision will become easy to make.

Group Dynamics Part II

I thought it may be a good time to update my thoughts on how the dynamics of working in a group are going for me.

In one word--difficult. It is proving to be much more difficult than I anticipated. I don't believe this is due to any failing in the group members, in fact I believe our group is exceptional and well balanced. No, I believe it is due to the fact that I just have never before been involved in a group project of this magnitude and the difficulties have taken me by surprise.

I have come to realize that communication is incredibly important. I knew this was true in theory before, but in practice it is being emphatically proven. Having worked primarily on my own, I am used to allowing ideas and models to undergo slight changes in my head and being able to maintain consistency in the logical operation and interaction of these models. This is proving to not be the case in group work (unsurprisingly). If I change how I envision a piece of the project working and don't communicate the change, however small, to the group it turns out I have a bad time (again...unsurprisingly). This is also true if I'm not explicit or entirely clear with my ideas.

This is why communication is going to be a focus for improvement for me over the coming weeks.

Goldilocks thinks my learning algorithm is just right.

I'm going to discuss the reasons and advantages of the learning algorithm I proposed and implemented for the diagnostic graph traversal, and why I think it is a good choice.

In the simplest case, we could've implemented a graph traversal algorithm that has no learning aspect. This would've been the easiest option as we all have implemented a DFS or BFS before, probably in a variety of settings, and will almost certainly do so again. But this would've been turning our backs on one of the best potential features of Mechanapp. Without any learning aspects to our application there would be nothing to set us apart from other similarly featured applications.

We also could have gone to the other extreme. Part of my research touches on the state of the art in machine learning. A variety of these algorithms would've worked for our purposes and maybe worked very well. There are problems with these though. Many of them require extensive training sets, training sets that we don't have. They may take a long time to become effective. The largest problem though, is that many of these algorithms are just too complicated. They are difficult to understand, difficult to implement, and difficult to debug. This just wouldn't work for us.

This is why I chose the simple learning algorithm that we've implemented. A greedy graph search with learned edge weights is simple. Simple enough that every member of the group has the background to understand it FULLY. I won't need to distribute machine learning papers to provide the other group members and myself with the background necessary to understand it. Additionally, in its simplicity it was easy to implement. I implemented two different versions in two different languages in one week. And it's exceptionally easy to debug due to its simplicity. These things are great, but the best part is, it will work. I believe it will work very well for our purposes. For these reasons, the algorithm is not too little, and it is not too much, I would say--It's just right.

Quantifying Developer Quality

After having written my self evaluation, I've spent some time thinking about the quantifiable assessment of a developers quality. In my self evaluation, one of the major metrics I pointed to as evidence of my efficacy was the number of commits that I made. I did this partly because I made a lot of commits, so this metric was good for me. But additionally, I really think that it is be a good metric by which to judge a developer.

It is true that if you judge purely on number of commits, a developer could game this system by committing changes every time a comment is made or a line of code is written or changed. This could have a negative effect on the code base and make the commit logs opaque and useless. But if this very specific problem is avoided through some kind of monitoring process, then I believe commits can be a good quantifiable metric.

A large number of commits means that the developer is active. Additionally, it shows that the developer is thinking about the problem in small pieces (the parts changed between commits) which I believe is a good style of coding as it allows for easier debugging as well as frequent testing. It also allows other developers frequent access to the code during the development process which they may find useful in their own section of development. Finally, it serves to frequently remind the rest of the group, and oneself, that constant progress is both a good thing and an expectation, moving the overall progress of the project along at a good pace.

For these reasons, I think that commit logs, and the data they contain, are a good and useful objective measure of a developers efficacy.

Thoughts on Functioning Demo

At this last weeks client meeting with Nikan, we were able to present to her a demo that we were very happy with. The demo allowed the user to select a make, model, and year of vehicle from the drop down menus, as well as a symptom (just one for the proof of concept), and then to begin the diagnostic process. This then resulted in a complete circle through the UI->Framework->Graph Traversal Logic->Database->Graph Traversal Logic->Framework->UI to have the first diagnostic question displayed on the website with the available responses. I believe that having this demo available was very good and allowed the client to see one small but very important piece of what the user experience is going to be like in the end. This resulted in the first client meeting where we were able to leave feeling good about what we had presented and the reaction it garnered.

I think that this trend will continue and is due to the fact that our individual tasks are coming together and being integrated into a cohesive product (which is much easier to show in the limited time we have with the client). I am looking forward to having an even better demo for the clients at the next meeting and am enthusiastic and excited about the progress this group is making!

Caught in the Middle

Over the course of identifying how the code from each group member is coming together we have settled on a scheme where my code is acting as a layer in between David's server and web framework, and James' database code. This provides me with a unique challenge in that I must make sure that the code interaction with both other group members is consistent and provides logically correct function, while doing so in an individual context with both. We have had group meetings where the entire interaction has been enumerated, but the details of the interactions are being worked out on a personal basis, in so far as James and I will discuss and refine our interaction, and separately David and I will discuss and refine the other interaction. I have found it challenging to maintain consistency between the two but believe as of today to have succeeded and I believe the whole code base is almost integrated (in prototype form).

Sub-Group Meeting

Today James and I had a meeting between the two of us integrating the database with the graph traversal code. The meeting was very successful and the integration appears correct. I will write a test suite to confirm correctness this coming week. I must admit that the integration with the database is going much more smoothly than I had anticipated. I am also extremely satisfied with the way that the graph traversal algorithm has turned out. It is very simple and easy to understand--yet effective.

Group Meeting re DB, Graph Traversal, and Frameworks

Yesterday we met to discuss our progress on our action items. Everyone is making solid progress (although I'm the only one with a recurring Back to the Future theme in MY progress...) on their action items, but the real revelation that came out of this meeting is how our various pieces are going to be interacting. We went through a pseudo-function call by pseudo-function call example and solidified this interaction. This allowed me to get a firm grasp on what exactly is going on (which means I can code it better now). I also finally know what a web framework actually is, so that's nice. We also were able to settle the issue of what our database schema is going to look like. Details to follow!