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.

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!

Updated Group and Individual Timelines

Graph Traversal

Graph Traversal Example:

Below is an example of a small instance of how the graph traversal will interact with the user (as currently visualized), as well as how edge weights will be updated to facilitate learning.

Example graph state where we’ve initially determined that the user drives a sedan and the symptom is that it wont start.  Our traversal begins at the “Won’t Start” node.

At each step of the traversal we define and display the probabilities of each leaf node that exists down the tree as the product of the edge weights in the shortest path to the leaf. As we are at the “Won’t Start” node, the probabilities would be for example:

Out of Gas: 36%

Spark Plugs Are Bad: 24%

Battery is Dead: 32%

Starter Motor is Bad: 8%

These values are updated at each step of traversal to give the user an updating list of probable problems.

Traversal:

We do a greedy graph search using the edge weights defined by the probabilities p. We reach the “Turn over?” mode at which point the traversal needs user input. The probabilities associated with the edges out from this node are built from past traversals, i.e. what users have expressed in the past. The application will ask the user for input at this node, specifically asking if the engine turns over when the key is turned. Lets assume that the user responds that it does indeed turn over. We then proceed to the transition state, a state that does not require user input and will proceed to the next state based on edge weights. In this simplified example we then reach the answer state “Out of Gas”.

At this point we have an answer for the user, their car may be out of gas. We would inform the user that this is probably the problem and perhaps provide a link to a video showing how to add gas to their vehicle. At this point, we will wait again for user input. Specifically we want the user to tell us if this was the problem. For this example let’s assume that the car was not out of gas, and we haven’t fixed the problem. The user informs the application of this, and traversal continues by going back to the transition state and proceeding to the next leaf node--the answer state “Spark Plugs Are Bad”.

We again recommend a DIY process or a mechanic to fix the problem and prompt the user for feedback. Let us assume that this did indeed fix the user’s vehicle. At this point we trace back the path and update the probabilities of each transition to reflect the new data.

This new graph structure represents a better informed graph and will be used for the future sedan queries and all graphs inheriting from the sedan graph.

Group Work Week 1

Here are some thoughts on how the group has been working together so far after one week.

Overall I have a very positive impression of our group dynamic. It seems that everyone is both responsive, as well as willing to work hard this semester. Additionally it seems like our personalities will fit well together to say nothing of our CS skill sets--which I believe complement each other's almost ideally.

I am happy with where I have landed in the division of labor and believe I will be able to make a significant and novel contribution to the project through my domain.

I am sure there will inevitably be rough spots in the coming semester regarding the group, but it is encouraging that these haven't cropped up in week one.

We have almost completed the logistics portion of the project set up (repositories, cloud resources, etc). I think this will make our group interactions more productive and less banal moving forward.

Generalized Division of Labor

Having had a small amount of time to speak with the other group members we have discussed our strengths and come up with a high-level and tentative division of labor:

Sonny:
Sonny has extensive experience with web design both functionally and aesthetically which is wonderful as this is probably my weakest area personally. For this reason Sonny is spearheading the front-end of the web design.

David:
David has agreed to pursue the "back-end" of the interface which as I understand it will act as a layer between the UI and the algorithmic logic of the program.

James:
James has experience through work with databases (another area of knowledge I woefully lack) and subsequently is going to be heading the database work for now.

Alan:
My particular strengths lie in the algorithmic side of CS and as such I believe I will be well suited to addressing the algorithmic logic of both the graph traversal as well as the learning portion of the application. The group has agreed to make this an area of focus for me.

Client Meeting 1

After having our first client meeting one thing has become abundantly clear. It is time to hammer out the specifics. Up to this point, through the proposal process and in the very short time we had as a group prior to the meeting, the whole project has been discussed in the abstract. At the time of the meeting we had talked about action plans to take steps to solidify the ideas but had not actually done so. I think we would've been in a better position to have a successful client meeting if we had discussed actual implementation and design.

This is encouraging though, because the details are currently being addressed, and I believe that implies our next client meeting will be much more successful. Additionally, with an attempt having been made at some amount of division of labor, we will be able to more personally contribute to the next meeting--rather than staring at each other awkwardly until James spoke.

Ranking Conundrum

We are about to rank the proposals so that we can be placed into groups. This is really exciting because after listening to all of the proposals the last three days there are a number of projects that I find extremely interesting! It will be a difficult ranking process, especially where I will rank my own project which for whatever reason has lost some of its luster.

I am torn here. On one hand I think I will perform better this semester if I am working on a project that I find very interesting. I will find it more natural to remain engaged in the face of this, the most difficult and busy semester of my educational career. On the other hand, if I rank my project first--ahead of some projects that, embarrassingly, interest me more--and it is chosen, then I will be ahead of the curve on the "impact" portion of my grade, a concept which looms as an incorporeal boogie-man in the bedroom closet that is my uncountable fears regarding my last semester as an undergraduate.

I have tough decisions ahead.

Proposal Writing, the Aftermath

The proposal writing process was an educational experience. The task of creating a formal proposal document was new to me. I've had experiencing writing technical papers about research, as well as experience writing legal documents when I was a paramedic, but never before have I had to sell an idea in a formal document. Especially difficult was the balance between the "real" portion and the "pretend" portion. The real portion of course being the parts of the proposal written with the context of a 12 week project in an undergraduate CS class, and the pretend portions being things like the budget and support sections which due to the context of the semester long class had to be fabricated.

Regardless of this difficulty I found the writing process to be very educational as well as a tool for focusing my intents and taking a much more formal look at what it was exactly that I was proposing--an experience that will change the way I view future projects.

Proposal Final Draft

The final draft of my proposal can be found at:

http://cs.unm.edu/~adkuntz/AlanKuntzProposalFinal.pdf

As always comments are more than welcome!

State Pattern, a Behavioral Design Pattern

One of the more intriguing design patterns I read about while perusing the software design pattern wiki was the state pattern in the category behavioral design patterns.

This pattern hinges on a characteristic of a programs objects called state. The state of an object (can be an object itself) is used to allow the original object to have multiple behaviors. Part or all of the behavior of the object is actually dependent on the state variables or state object of the original.

This simplifies the way in which the program has to handle these objects. The program need only update the state of the objects (although I suppose they could update it themselves in some implementations), and then treat the object the same regardless of the state and the object will adjust its behavior accordingly.

I find this design pattern to be particularly powerful in one main way--it allows for a large conceptual and programatic abstraction of each object that aligns well with my understanding of an "actor" model of conceptualization. Particularly, a program can be conceived and developed as a stage for the interaction of various actors (sometimes objects), and define the rules for the interactions of the actors which algorithmically results in desired behavior.

One area I have used a concept like this in the past is in experimenting with multi-agent robotic algorithms.

The state design pattern is particularly powerful in this setting, as we can allow the actors to perform various roles or behaviors based on the state of the system which allows for more complex behavior and interaction definitions.

I will definitely be considering the use of this pattern in the future.

Three Words

To describe my ideal project team in three words, I would say:

Excited, Dedicated, and Punctual

I chose these words because these are the characteristics I believe will facilitate the best experience for the group as well as the best final product.

Excited--I believe that a group that is excited about their work will inspire each other to be better group members and make the process less tedious and more enjoyable.

Dedicated--My ideal group is willing to work hard even when the project becomes difficult. A group dedicated to their work will be willing to add that extra effort to produce a high quality product.

Punctual--With such a narrow window of time to perform in, punctuality will be a high value commodity. Planning without punctuality of deliverables would be impossible, and as such punctuality deserves a place high on the list.


If I could include three more words I would include Personable, Proud, and Talented.
Person to person interaction skills are important in any kind of group setting as well as in a developer client situation. People who are proud of their work generally produce better work, as well as are better at selling it. Software Engineering seems like a difficult occupation, and as such I believe the best engineers will also possess some amount of talent.

Proposal

The proposal for my mobile application "Backpacker" is up and available at:

http://cs.unm.edu/~adkuntz/AlanKuntzCS460Proposal.pdf

Comments are most desired and welcome!

Try this URL instead:
http://www.cs.unm.edu/~adkuntz/AlanKuntzCS460Proposal.pdf

"Backpacker" Project Timeline

Week 1:
Client meetings
Discuss and decide on design characteristics
Discuss and decide on platform (Android vs. iOS)
Install and get familiarized with development tools (Xcode/Eclipse)

Week 2:
Client meetings
Create "Hello World" app
Research feasibility of feature set (e.g. will iPhone allow an app to send a text message?)
Discuss feature set with sample of target user group
Construct app "Story board" (page layouts, user experience)

Week 3:
Client meetings
Divide features up among group members (perhaps work in pairs)
Begin feature development/documentation

Week 4:
Client meetings
Development/Documentation

Week 5:
Client meetings
Finish development
Combine features into working prototype

Week 6:
Client meetings
Group tests app, develops bug list and notes on app refinement

Week 7:
Client meetings
Discuss findings of first prototype testing
Decide on changes
Begin changes

Week 8:
Client meetings
Finalize and aggregate changes into second prototype

Week 9:
Client meetings
Group tests second prototype, develops bug list and notes on app refinement

Week 10:
Client meetings
Discuss findings of second prototype testing
Decide on changes
Begin changes
Begin marketing process (forum posts, blog posts, Reddit posts)

Week 11:
Client meetings
Finalize and aggregate changes into final app version
Short final test
Marketing

Week 12:
Client meetings
Package and release final app version
Final marketing push

Backpacking Mobile Application Proposal

People who embark on multi-day backpacking trips experience the wilderness in a different way than any other type of adventurer.  Frequently many days from the nearest signs of civilization the isolation is second to none in this activity.  Additionally, often every supply and resource needed for the duration of the trip is brought in from the start making the activity one that is both strenuous, dangerous, and requires careful planning.  I believe that some of these needs can be targeted by a carefully and specifically designed mobile application.

Our team will design and create a professional backpacking assistance application that meets the specific needs of backpackers through the implementation of a couple of novel features.  The application will provide a GPS based log of the backpacking trip, while accounting for the battery life requirements of multiple day use without the ability to recharge.  Additionally, the program will provide a planning tool in the form of a gear inventory checklist including consumption rate tracking for both water and food.  Another novel feature that will be implemented is an emergency notification scheme, which will send an emergency text message with specific details (like GPS location) the next time the phone has cellular service.

Mobile phone users who backpack will find this application very useful due to the specific targeting of their needs.  We propose to sell the application at market competitive prices.  Please consider helping with the initial costs associated with the development of this novel application

Software Engineering, Initial Thoughts

As I read the software engineering wikipedia entry, I couldn't help but follow two thought processes which were--for me--novel. The first, is how different the two concepts of software engineering and computer science, as I've experienced it, are.

In my education process at UNM I've certainly been exposed to both, and it does seem that the concepts behind software engineering are being included as a subset of the computer science curriculum. But I've always had this nagging feeling that I was being taught the content of two related but distinct professions, software engineering and computer science.

The wiki at first glance confirms this concept, and tells me I'm not alone in my impression. It does seem that the software engineering degree itself, already offered at some places, is gaining traction in academia and in industry. This is evidenced by the stance of the Professional Engineers Ontario (PEO) which holds the two distinct and has reflected the view in the construction and implementation of their licensing process.

I believe this is a consequence of the rapid and organic growth of the computer science field. Furthermore, I believe that we will see more relaxation and re-categorization of computer science subfields as time goes on. Computer science is a broad discipline which spans relationships with many other fields. We, as professionals and academics, will take some time to sort it out into natural and meaningful categories.

Personally, I find the fact that I am going to be involved in this process very exciting.