Software Engineering--Final Thoughts

I'd like to conclude this semester with a reflection on software engineering--the discipline, and how my viewpoints have changed over the course of the semester.

Initially I was a little skeptical about software engineering in general. I have exposure and experience in research in computer science, and I viewed the differences as stark. I was unsure how I would take to it or how enjoyable I would find it.

One thing that surprised me was how much the two disciplines went hand in hand in our project. I found the science infused in every day choices throughout the semester, regarding things like algorithms and data structure choices. It was also interesting to me how much above and beyond the science the engineering was. There is so much more to creating a good product than understanding how it should work and the science behind the implementation.

My views towards software engineering are definitely different and I think the perspective I gained this semester is wonderful. I now know much more about what being an engineer actually means and am confident that I would both enjoy and be successful in an engineering role.

I am going to take some of the lessons I learned in this course and apply them to my own research as I go to graduate school. I will continue to allow the science and the engineering to work together in my work, as I make this a priority. I believe this approach will benefit the quality of my work in the future.

Group Postulations for the Last Time

I wanted to reflect with some finality on how the group interactions went from my perspective in Mechanapp.

It was an interesting semester and it had its ups and downs. One thing that I am sure about though is that our group was very good. I have absolutely zero complaints about any other member of my  group.

I thought that our individual skills and personality traits complemented each other and allowed for an enjoyable, effective, and efficient project.

Sonny's UI work was absolutely stunning and flawless. David's knack for code interaction, the web framework, and all the research he provided for the group was invaluable. James' database expertise and leadership allowed for smooth group interactions both in and out of the context of the database.

I could not have asked for a better fit in a group and am frankly surprised at how well it went for us.

Awesome--Second Place!

Mechanapp received the honor of winning second place at the presentations yesterday. We are extremely happy and somewhat surprised! After having seen the hard work and polished products of the other groups it became obvious that there was some steep competition.

I am exceptionally satisfied with our final product. I believe it to be an impactful, useful, and polished product in its own right. It was an honor to have that affirmed by the professionals Professor Ackley brought in to judge the projects. I also was very appreciative of the insightful questions and feedback the judges brought to our group.

The conclusion of this project is bitter-sweet for me. It has been an extremely rewarding and educational experience.

Preparing for the Presentation

Tomorrow our group is meeting to hammer out and practice our final presentation for this course. It is exciting to be putting it all together into a single pitch. I am also happy that the entire group will have roles to play in this presentation (unlike the previous ones).

The details are still up in the air, but I think the distribution will be something like:
James does the introduction, business side, and a brief user case demonstration.
David then takes over and overviews the technological choices.
I (Alan) will then proceed with a demonstration of the learning feature of the application.
James will then conclude the presentation.
As per the usual, Sonny will operate the laptop and assist as the user in the demonstration.

My only concern with this setup--and it's a minor one as I am really excited for the change--is that we will have difficulties keeping the presentation under the time limit. We may find tomorrow that there are just too many features to proceed in the fashion that we have planned. We will see though, and I'll check in after the meeting tomorrow.

Social Media Login Thoughts

David and I recently modified our login approach to be handled on the side of the server. This is necessary we believe as client side authentication just doesn't mean anything. In some cases that may be okay if the authentication was desired for superficial reasons, but we needed a stronger form of auth to handle our commenting system. 

Initially we researched and implemented a plug-in (with associated api) called SecureSocial. This plug-in made a lot of things very easy, and after awhile we had authentication through google accounts working well. This had to be done working in conjunction with the google developer console for registering client-ids.

There was an opportunity to use other social networking sites as well for authentication such as Twitter and Facebook, but the barrier to entry for developers was higher for these sites (and lets be honest, twitter just isn't a necessary feature for a DIY car diagnostic assistance tool).

SecureSocial is no longer how we go about the authentication for our app, but the knowledge gained by working through their documentation as well as their api enabled us to move forward with the processes that eventually became the permanent solutions.

Comments and the Art of Troll Avoidance

We recently decided to add commenting to our application. This made me immediately nervous as I suspected that within a few milliseconds of going live our website would be flooded by troll comments talking about how our mom's wore army boots when they fixed their Ford, or other such nonsense. As much as a right of passage as this would be, I do believe it is something to be avoided if possible (it probably isn't) or at least minimized.

We discussed this as a group briefly and decided that our approach would be to make commenting a function for logged in users (the log in being through a google account. This means that while there is no real protection from dedicated trolls, at least the veil of anonymity will be removed and if they want to postulate on the state of footwear of our mothers, at least they will have a name.

Striking a Balance

One thing that has been coming up quit frequently recently is the need to strike a balance between treating this project as a school project and treating it as a production piece of software as if from a software engineering company.

This has come up mostly as we realize that some things that make for good production level software actually cost money. Like real american dollars.

We really want to produce the best product possible and if we could maintain the illusion that we were a software engineering firm making a real life piece of software this would be ideal. But the fact is that we are not being paid for this (the opposite is actually the case), there is no company to fund development costs (all expenses come out of our pocket), and in all likely hood, the differences will not be missed by many (if any).

As poor college students this is turning out to be a difficult balance to strike. Do we pay a lot of money for a nice tls cert, or can we go the free self signed route? We have already invested money into things like presentation supplies and domain names. We keep having to address this issue and it is difficult.

I think that we are producing a professional quality product in the ways that we reasonably can--the coding. We have gone out of our way to use industry standard code practices in web applications. In this area the balance is clear, be as professional as possible. In the financial domain, it is less clear.

Server side Google+ and Facebook Authentication

David Strawn and I have been spending a lot of time recently beginning the implementation process of server side Google+ and Facebook authentication. We have decided to go with a Play plug-in called SecureSocial.

This has been a very educational experience for me, as I have gotten my hands dirty with the web application coding that up to this point had been done mainly by David alone. Having to edit the routes file, the .conf files, troubleshooting play specific annotations; these have all been new to me but very enjoyable.

This has also made me appreciate the work he has put in up to this point to fully immerse himself and understand the framework we have chosen, as it is not intuitive but once understood is very powerful.

We are hoping to have this functionality complete this week (and then I am really hoping we stop adding features and do a comprehensive testing and consolidation prior to the final product debut).

Presentation Reflections First Three

This last week the first three groups gave the second practice presentation. For me this marked the first time I had been a part of the presentation with about half of our groups presentation falling to me. I thought this went very well and people seemed to respond well to the portion I presented specifically.

The other two groups that presented have seemed to improve their presentations as well. The talks seemed much more focused and polished. I am looking forward to seeing the other three this coming week.

I am very optimistic that my participation in the presentation will help to improve my impact score in the grading scheme. With the release of the interim grades this last week it is apparent that impact is the area I should focus on in the remaining three weeks. Since a lot of focus was put on the group project proposals in the first part of the semester I am guessing the same will be true for the group presentations at the end.

Presentation

I am very excited to be a part of the presentation tomorrow in a larger capacity than last time. I am being asked to present some specific functionality of the graph traversal's learning. I very much enjoy presenting and am glad for the opportunity.

I am slightly concerned that the transitions between James and myself will not be smooth but am confident that we will be able to do a sufficiently good job.

I also believe it will be very enlightening to see how the other groups have improved their presentations/applications in this round of presentation as compared to the last round. I think that our group had one of the stronger presentations the first time around. For the most part the groups did well but it was sometimes apparent that there was not much practice time spent on the presentation itself.

To assure this was not a problem that we were going to have Sonny, James, and I met for a few hours this afternoon constructing the specifics and practicing the presentation. Tomorrow the value of this work will be revealed I suppose.

Learning Demonstration

My action item for this week is to create a demonstration of the learning functionality of our graph traversal algorithm. This is important, I believe, because it is one of the best features of our application and really sets it apart.

I am worried though, because it is not directly related to the user experience(UX), the user benefits from the learning but not instantaneously, a user really benefits from past user's experience. I am trying to balance the need to focus on the UX while still maintaining some amount of focus on the other stuff as well. The UX is very important, but there are things that are important as well but only relate to the UX in a tertiary fashion.

I am going to need to be sure to sufficiently emphasize the relation the demonstration has to the overall goal of the project as it relates to the user. There are other parties at play here, and this demonstration is the most important for potential investors, as well as for advertising. It should be interesting to go from here.

Need for User Logins

We have decided that it will be very important in the near future for the user to have the capability to log in and save progress during a traversal.

This realization came after our presentation when it was astutely pointed out that some of these diagnostic procedures may require a long time to complete, and if the progress is not saved it would be very unpleasant.

We are currently investigating ways to make this happen. I believe this will be part of upcoming action items.

Presentation Thoughts

After having presented this week I believe our project is doing very well. Being able to see the state of two other groups was very helpful and I am excited to see the rest of them tomorrow. It seems like every group so far is pretty much on the same track, functioning prototype with a need to complete the implementation of a few features. I thought that aesthetically our application is looking exceedingly good, and we have begun to seriously consider the user experience. I am very content with where this application is for the amount of time remaining, a pleasant surprise since I anticipated being in full blown panic mode by this time.

Group Dynamics III

I think the group dynamics are getting better as we learn to work together. Some of the initial tension is gone as people have learned to trust one another to be good at what they do. There are still some communication issues, particularly on my end (it may be the case that I'm bad at explaining algorithms, which does not bode well for my intended future career in academia). Additionally, I have difficulty letting go of control. James is turning out to be an adroit and capable leader, I am just not used to being led. Spending a few years as the paramedic in charge of patient treatment in a 911 system will do that to you turns out. As I come to grips with not being in full control, other people have improved in their dynamics as well. This is a capable and pleasant group, and I am very happy with how this is playing out.

Aesthetics in design

I've begun to examine our specific user experience (UX) and after our last client meeting I realized there is an entire portion of the UX that I have neglected to even consider--the aesthetics.

This shouldn't come as a surprise, the best designs in the world come from people who are notoriously good at taking aesthetics into account. This is what makes companies like Apple and Starbucks so successful.

What is our aesthetic goal? Prof. Ackley described a choice of background image to specifically address our target audience. This is a very interesting idea. How can we through our aesthetic design choices create the "feel" that our targeted customer will be comfortable and happy with? It has to come from a concerted evaluation of who that is, and what they like. A Feng Shui for our application if you will.

Useful Features, a Reflection

In our last client meeting it was pointed out to us that the search box we had implemented was fraught with danger, a trap, a feature that had the potential to make the user experience (UX) worse rather than better. I must admit this took me by surprise. How can additional features be bad? Isn't increased functionality always a good thing? These are the questions I found myself asking and the answers changed how I look at application development.

How do I look at application development? Well first of all, I look at it with the dow eyes of a developer on his first project. Never before have I had to implement ANYTHING with a user in mind that wasn't a CS professor, TA, or fellow researcher. This is a totally new concept to me so perhaps my viewpoint isn't as refined, practiced, or good as other developers. I've always operated under the assumption that more features are better, and in my work it holds true for me. A tool that includes more motion planning algorithms is just better than one that doesn't--says the Alan of last week.

I've been forced to reflect on this though. As I cycle through the stages of grief for my dead search bar feature, I must analyze and eventually accept the premises that lead to it's death. This is my responsibility as a student.

What made it a bad feature? I am standing by the fact that it was a feature, I don't think that word should be defined to only include the good ones. If you start with the assumption that it was indeed a bad feature, then why?

It was bad because it was distracting. It provided a place for a user to do something unexpected and become distracted by the outcome. We are targeting a set of people that maybe don't want bells, whistles, or string edit distance assisted symptom definitions. It's too much. The UX needs to be simple and intuitive.

Overall, this has led me to view features different. I should no longer only ask is this feature functional, does it add capability to the application, but rather other questions. Is this feature right for my targeted user. Is this feature intuitive for them or align with my understanding of their expected technical skills. In the case of the search box of Mechanapp, it is not right, it is not intuitive, it is bad.

Is this acceptance Dr. Kübler-Ross?

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.