Tuesday, June 16, 2015

Tell an interesting story about yourself (some of the best advice I ever got)

I was at a company sales meeting in New York City this past weekend.  I know, normally not my cup of green tea, but it was actually an awesome event.  I got a chance to touch base with a lot of my customers, get valuable feedback, hear from a great speaker, launch our iPad app, and even go out and have a good time.

The meetings took place over the entire weekend, starting with a reception Friday night and going solid through Sunday evening.  On the final night of the event we had a small awards banquet, and were provided assigned seating.  This meant, of course, I wasn’t able to sit where I would be comfortable and among those I normally associate with.  Then again, this isn’t so bad of a thing.. it get’s me more involved with others, and many of these folks I knew on a casual basis anyway.

So one of the socialites of the group said “OK, lets go around the table, and everyone introduce yourself and tell an interesting story.”  So of course, they start with the gentleman to my left, and by this order I’ll be the last person to speak. Over the next 15 minutes, each person follows suit, providing details about themselves, talking about various accolades and crazy sales trips they’ve been on.  Finally they get to me, and at this point everyone is talking amongst themselves.

GOOD!  I thought everyone lost interest and they would forget about me.  Instead, the socialite said “Hey! It’s Eric’s Turn” and everyone went back to drinking moderately and staring at me making me rather uncomfortable.

So I gave my brief introduction (married 9+ years, have a daughter, etc.).  And then I gave my story, which was the only story I could think of.

When I was a senior in high school, I took an Advanced Placement programming class.  It was in C++, and the whole idea is that if you take the AP exam and score well, you get college credit.  At that time, the exam was scaled on a 1-5, 5 being the best.  I took the exam, and I got a 1.

Dejected I did so poorly, I went over my girlfriends house, who’s father was working for IBM. When I told him how I did, and mentioned I was going to change my declared major from programming to something else, he told me that you don’t go to college because you know everything, you go to college because you know nothing.

So, I stuck with my major, continued to struggle with software development, graduated, and kept grinding and working on getting better, and hope that I’m halfway decent enough to provide help today.

Well, the brief memoir was met with instant applause, I felt really proud they enjoyed the story, and even prouder I was able to think of something to say other than a silly joke.

However it did make me reflect on what I do, where I’ve come from, and how far I need to go.  It was a great reminder for me to remember that I am far from gifted in my field, but I am fortunate enough to enjoy what I do, enough so that when I have a problem or am interested, it’s hard work and dedication (just like anything else) that helps me continually improve and grow.

Thursday, June 4, 2015

Going to the App Store – Lessons Learned

In late April, 2014 I was an attendee at the Windows Build conference.  Conferences are a great way to “get out” and focus on higher level items rather than fight through the weeds.  A number of conference sessions focused on apps, user experience, and data services, and it got me thinking “why don’t we have an app” (we being the company I work for).  Simultaneously, our CEO was walking around the home office saying “why don’t we have an app!?”  The CEO wanted an app, that’s the ultimate blessing for a project, and away we went.

Late April of this year, and we we’re putting the finishing touches on the app, and it’s amazing to look back and see all the lessons learned throughout the process. As a software developer, there have been so many times I could take an idea and start to make it real, even if only a proof of concept.  In the iOS world I can’t do that however, I dont have the toolset to scaffold out an app, it’s just not who I currently am.  So, the internal team and I had to start from square 1,which was finding out who could possibly build this thing.. and along the way determine what “this thing” could be!  It was a great learning experience, and looking back I think these are some of the key takeaways.

1. Know your customer – This isn’t a recommendation on how to come up with a killer app, this is how an outsourced development firm should treat you. We had a number of mis-fires throughout our development period, mostly due to a simple problem, our offshore team didn’t understand what we do.  Our app is to help sell vehicle service contracts, our offshore team wanted to design software and write code, not learn about US manufacturing and warranty periods.  The problem was, the “simple” parts of our application – show videos or PDFs – they ran with.  The most critical pieces they fumbled along the way because they inherently didn’t understand what data the app needed to handle and disregard.

2. Know how to track issues – Our offshore team used their own custom software to report issues, track feedback and answer questions.  The problem was, it was essentially a private discussion board.  So, imagine what life was like when we received a new release, tested, and posted feedback to the system as one massive message.  There were no “tracking numbers”, instead our tracking system involved referring to items like a Friends episode - “that one issue where the app crashes if you don’t enter any data on the fourth field”.  We also lacked any categorization – all issues were just that, issues.  What was important and what wasn’t was difficult to follow.

During the final few weeks of development, we took over bug tracking capabilities.  We went somewhat old school, just an excel spreadsheet, but it logged each item as an individual task, with priority, examples and dates.  This was the decision that helped put our app into the store.  We were able to categorically indicate “we have 20 critical\high issues that we need closed” gave the offshore team a focused intensity towards what was important and what wasn’t.  It also helped us communicate internally how close we were to launch, and if deadlines were going to be impacted.

3. Know when your partnership changes – Another issue we had was how our development process progressed with our offsite team. The first half of the project was all design – pictures, images, text – how will the app look and feel. What will it do.  Forget how data will input and output, what will this thing feel like.  Once our design was signed-off, most of the designers moved on to another project.  The problem here was, there was a “reason” we designed things a certain way.  We talked alot about the emotion and meaning behind our imagery, and our use cases on how a screen would work.  When developers were making the app work, they didn’t inherently understand “why” we did certain things certain ways, and the functionality came out clunky and took a lot more time than anticipated to make the app work.

4. Know how to motivate people to test – We had a number of meetings during the past year, and many of them involved conversations that boiled down to “this is THE most important project you are working on.”  It really helped understand that nothing short of a production outage should take precedence over working on this project.  It was rather aggravating then when it came time to test and we couldn’t find anyone – not a single soul – to help test our app.  We would send emails, chat in a hallway, place phone calls and talk to managers.  Finally I had had it, I sent a plea for help to the requested testing team – 10 people in total!  “Please”, I said, “We desperately need your help! Just one hour of your time!”  I even offered to purchase lunch to whomever could find the most defects.  2 out of 10 people tested (and yes, I bought both of them lunch).

The optimist in me tells me that this final plea came at a bad time, that my co-workers aren’t heartless employees who don’t like a free lunch, but that if I gave them a week to test rather than that one day, I would get results.  The problem was, we were asking for weeks on end for help, timing never really worked out, and in the end a majority of the testing was done by myself and the 2 people who worked on the project with me, which wasn’t the same amount of hardline testing we were hoping for.

5. Understand Apple Trademarks – So apparently, if you name your app “Company XYZ iPad App” – you’re not only in trademark violation, your app will get rejected.  However, if you name your app “Company XYZ App for iPad”, you’re fine!  We didn’t know this, and it caused our app to get rejected almost immediately when we published for review.  Fortunately, it was a quick turnaround to change our title and get it submitted again.

6. You can request an expedited review of your app, but it still takes some time – We submitted our app, and within hours we were getting it reviewed.  Our app had some basic features, and within 24 hours we were approved to go to the app store, solidifying that we would hit our deadline.  Then we learned that the waiting is the hardest part. It took another 36 hours since original approval to actually appear in the app store! 

All in all, many of the items above aren’t so much “app” lessons learned, they’re more or less general items that relate to any software development project.  Still, all’s well that end’s well, and we’re proud to have our first app in the store, and hopefully this is the first of many.