Presentation reflection

I think that, overall, we did pretty good on Monday.

It's kind of hard to tell if you're getting your points across during a presentation sometimes.  I felt like I was explaining everything the way I meant to (mostly), but there's usually that doubt anyway.  A couple other students in the class said the presentation was very clear, so I hope that's true.  Our website looked good, as did our one-sheet handout (thanks Sonny!).  I think the team looked pro; we were well-dressed and gave good introductions.  The precise description I gave to everyone of the presentation plan really, really helped.  It made everything smooth and predictable on our end because everyone knew already what was going to happen (or, at least, I did :) ).

I found Ackley's criticisms to be accurate.  I'm going to talk to David or Sonny about adding some kind of field in the database like a 'title' for each QuestionState, which can be displayed in a larger font.  That would help with presentations and demos, and also make the program feel more cohesive, I think.  That's a pretty simple addition for a good return on investment for the User eXperience.  Ackley also said the presentation didn't have a clear ending, it just kind of 'fizzled out' (or something like that).  He was right, and that was a result of not correctly anticipating where I wanted to end the demo and not quite knowing what I was going to say to conclude.  What I really needed was a quick review and summary to wrap it up and reiterate the main points.  Next time...

Meeting notes and work log - 4/5

We had a pretty productive meeting today (about 3 hours).

We selected a new background image for the website.  Sonny is going to do the facelift we desperately need so it will identify more with our target audience (hobbyist mechanics).  I am planning to get together next week with a friend that's into photography to take a custom photo for our background.  I'm thinking something with my car, hood up, some tools laying around.  You know.  Mechanic type stuff.

We also discussed some bugs and new features we will implemented.  I showed the group my newly redesigned "no start" diagnostic tree, which they liked.  It has a higher branching factor so that it can be better pruned by Alan's prioritizing search, and has a consistent node numbering scheme (increasing in left-right depth-first search).  I implemented and double-checked (hell, quintuple-checked) the database record for this new tree; it is currently in a separate copy of the database though, because a bug has arisen from the new structure (the code was supposed to work with this structure, but has shown it doesn't currently).

As far as presentation materials, I filled out most of the Business Model Canvas so we could use it as a reference to make our one-sheet.  Sonny is working on the one-sheet with the highlights of that BMC document.  I made the short Powerpoint presentation (two slides - title/intro and technical components) and it's ready to go.  I now need to rehearse my talking points (I'm the main presenter for our pitch on Monday) and talk a bit more with the group about the flow (in particular, with my 'driver' Sonny).  I'm going to make note cards for this purpose; I saw a few people use them for the individual product pitches way back, and it seemed to help.

Meeting and task notes - 4/4

We are taking the things discussed in our client meeting and putting them into action.

Our next feature to be implemented is graph backtracking, where people can cancel the answer that brought them to a present state and go back to the previous one.  To me, this feature is just critical for the user experience.  If someone makes a mistake, or doesn't like where the process is leading them, they need to be able to take a bit of control and retreat to some previous state.  This feature doesn't seem like it will be too costly, and will add tremendous value to our application.

Tomorrow, the team and I will meet for a code review and clean up session.  We have a list of issues and things we intend to fix during this time.  Some of these are for cleanliness, others are for robustness.  For example, we are looking to change the way my code casts objects from MongoDB documents to POJO's tomorrow to be less dangerous.  This will also be a good opportunity for everyone to look more closely at the other components of the project so we can all better understand the other modules we may not have directly worked on.

For tonight and before the meeting tomorrow, I'm mostly working on the presentation materials for Monday.  I filled out most of the Business Model Canvas and made the technical slide.  Tomorrow, the team and I are going to use the BMC as a guide to making our one-sheet handout for Monday.  Additionally, we need to discuss presentation planning and format and rehearse it a bit.

One day at a time I guess.  Weekends are for psychology students.

Client meeting reaction - 4/2

Whew.  That got a little heated.  In a good way, though.

Ackley told us some stuff we really need to hear about that state of our application.  Things that are much harder to see from the 'inside' as the development team.  Things like user experience and what a new user sees when they first come to our little world.  It was tempting to get defensive about some of the criticisms, but I think they mostly had merit.  I'm actually glad we can get honest feedback like that.  Per today, we are going to change the look-and-feel of the page; it currently has a kind of soft, open-road type of theme, which we will change to a more "mechanics and garage" type style (this is, after all, a mechanic's tool, no?).

There are also some usability features we desperately need.  One that came up today is the ability to backtrack manually in the graph search (i.e. cancel a selection and go back to a previous one).  To me, this feature is totally critical - users need to be able to have more control over where they are going.  We could also use more info at each state about why that state was selected - e.g. "Since you said the plugs are not sparking, we are going to check...".  Something as simple as that additional content would greatly help our user experience.

And then there's that search box.  A thorn in my side from day one.  We (somewhat reluctantly) agreed to add a search box for users to enter stuff into to try and parse out the issue they wish to diagnose with their car.  While it could be a good feature, it currently is unbalanced on it's return on investment (ROI) in my mind.  The drop-down boxes are a good interface, one that the user should understand, and one they have to use if they, for instance, want to buy auto parts online anyway.  So, I think for now we are going to scrap the search box.  Ackley is correct that, at present, it's more of a 'trap' or confusion to users than a help.

Overall, it was a good meeting and I think we got some good feedback as well as bad.

Work log - 3/28-3/29

Added some functionality to automate some database content addition.  In particular,  I wrote some code that will go through all of our QuestionStates (diagnostic graph nodes) and fill in corresponding Vehistory (value data for some particular car, used for greedy search) objects in the database for some given Vehicle.  I'm in the process of adding new unit tests for this code and I just updated some other unit tests for code that had changed in a couple ways.  In writing this code to script the addition of the Vehistory objects, I realized how ridiculous it was that I was adding so many by hand before.  For our last client meeting/demo, I added a full diagnostic chart to the database and needed corresponding Vehistory objects for each node in that graph (a minimum of around 35 in this instance) - so much copy-and-paste!  I guess what they say about that is true - if you're doing copy-paste stuff a lot while you're developing, you're doing it wrong.  Very wrong.  

Thoughts on hearing the talk by the head of Van Dyke

I was mainly surprised (though I really shouldn't be) by how many processes and rules the guy has to create and manage people (rather than say, technology and such).  I think as undergrads in Comp Sci, we have this impression that the hard part about this business is technical problems like programming and algorithm design.  In class on Monday, the speaker was making me think about how much of a people field software engineering really is.  If you think about it, we are in one of those areas where we often (hell, usually) don't produce a physical product, per se.  Rather, we produce an intellectual product, like a team of story writers.  When you think of it that way, you realize that software engineering management has a very different set of challenges than, say, running a paper mill.  It seems to me that a guy like Van Dyke spends his management energy almost entirely towards making sure his people are happy, productive, well-placed, and have what they need.  That sounds like the job of any manager, but a software manager appears to have less of the other normal responsibilities, like ordering inventory and raw materials or determining hours of operation and sales discounts (if one managed retail, bleh).  Van Dyke had a lot to say about ideas he cooks up or reads about and then implements with his team, like 'Bootleg Friday', a policy where every Friday his developers can work on what they feel is most important at that point (and not necessarily their main project).  His discussion of 'time buffers', which allow developers to have some room for error in their time estimates for tasks, goes to the same purpose; making his people happy and productive, yet accountable.  It seems clear that the reason Van Dyke Software is still around is because the guy who runs it understands that his most important (and in some sense, only) asset are his employees.  It's the same reason we're always hearing about the ridiculous perks employees at places like Google receive for working there.  Like Ackley always says, "software engineering is something that people do".

Client meeting notes - 3/26

Ah, a decently working demo :)

Today, we showed Nikan a demo of the user selecting a car type and symptom (though currently we only have one symptom chart implemented, that the car will not start) by either searching for it or using the provided drop-down menus.  The program then displayed a question/request to the user for some kind of diagnostic test (like "does the car's engine try to turn over at all?"), and there were buttons for each possible answer to the question.  In this particular diagnostic chart, every question is "Yes-or-No".  Through this interaction, the user (Nikan) was able to go through the chart in a simple way to try and diagnose the vehicle.  The user interface looked good, the program ran smoothly, and has real-life data being utilized.  It's looking like our core functionality is getting close to complete.

We still have much to do.  We haven't yet covered the case of when a chart doesn't solve a users' problem (they run through it but say nothing worked).  We wish to add some kind of form for this purpose that will email us with the complaint of the user.  On my end, there are database functions and tasks which I need to automate (such as adding initial Vehistory (Vehicle-history) objects to the database).  There is also content we need to add.  We have one full diagnostic chart with about 35 states in it; I envision that by projects' end, we will have something like 3-5 of these to provide a fuller picture.  There is also an idea of providing links to YouTube or Wikipedia at steps in the diagnostic process a user may find confusing.  This may be a good idea, with a good return on investment, but I'm currently more concerned with adding basic functionality and framework then straight up-content (same goes for new diagnostic charts).  Overall, I think the project is on schedule and we're doing pretty good.