Mobile App Journey - Part II

For convenience (mine namely), I shall refer to the HTML/javascript/CSS mixture as "HJC".

The next major point to cover is that while I know some HTML, some CSS, and some javascript, I am by no means an expert, at all, in any of them.  What I am good at is finding solutions to problems.

I suggest you read up on PhoneGap.  Then read up on PhoneGap Build.  If I were just using PG, then I would perhaps be using Eclipse and compiling using various SDKs for Android, iOS, etc.  PGB doesn't give me all the options that the Eclipse/SDK combination does, but it saves much time if you can live with what it does give you.

Next, I needed to settle on an editor.  Having a .NET background I could have used Visual Studio, but to try something (quite) different I chose JetBrains Webstorm, which ties nicely into Google Chrome (using the Ripple emulator) for testing.  There are any number of combinations you can decide on.  I'm not saying this is the best.

Next, I decided on what extra libraries I wanted to use.  My inclination is to use as few as possible.  I chose the ubiquitous jQuery, and Twitter Bootstrap.  I decided not to mix in jQuery Mobile.  jQuery has ease of use with making AJAX calls, notation, etc., and TB's framework does a good job of allowing one to build a web app that fits on about any screen.

We will leave PG out of the picture for now.

A reminder:  this series' purpose is not to teach you HJC (be thankful for that!).  It's merely retracing the things I learned and went through to get an app to market, using HJC and PGB.

to be continued...

Mobile App Journey - Part I

As for many, the idea of building and deploying a mobile app was for me a compelling idea.  This series will recount my decisions and actions to bring my first app into fruition.

Perhaps the first questions is:  native or HTML/javascript/CSS (from now on I will refer to these as 'native' and 'mobile app')?  For certain scenarios native is best or necessary, and yet for many applications a mobile app will suffice.

The second question then became:  if I go mobile app, should I try a hybrid approach such as PhoneGap (Cordova)?  There are other good hybrid choices such as Xamarin (although not free).

The advantages of a hybrid approach was that in theory I could write an app once, and have it deployed to Android, iOS, Windows, etc.  The other advantage of course was that I wouldn't need to learn Java, Objective C, and other languages.

Since my initial app was going to consist of gathering a few inputs from the user and sending the inputs off to a web service, then getting data back and displaying the results, I decided that the mobile app (HTML, javascript, CSS) approach was fine.

I then decided that "yes, I would like to be able to install my mobile app as an 'app' on Android, iOS, and Windows", and therefore I wanted a build solution that packaged my HTML, javascript, and CSS into a native wrapper that could be deployed as a native app.

After a week of back and forth I chose PhoneGap (PG), and more specifically PhoneGap Build (PGB).  PGB allows me to zip up my mobile app and upload it, and then PGB dutifully generates native apps which are wrappers around my HTML, javascript, and CSS.  Thus far I am happy with this decision, although there are some important details not obvious and which I learned about in Shawn Wildermuth's PhoneGap class on PluralSight.

to be continued...

The Everybody Meeting

Historically, in software development, one sure way to kill developer enthusiasm and slow productivity is to have the infamous "everybody meeting", daily.

These meetings come in many forms, but let's use the "defect call" call as our example. This is particularly painful when the team is large and spread across multiple physical locations. At any one time a particular defect may involve 5-10% of the people on the call. Rather than the developer, business stakeholder, and QA person discussing the defect together offline, they spend 30 minutes or so reviewing the ticket, re-visiting the actual business requirements, whether it really is a defect, etc.

The other 15-20 people on the line may have no interest -- and they are relatively unproductive while the conversation continues.

Let's assume $50 per hour per person. For 20 people this is $1,000 per hour. If 15 people are not engaged in the defect being discussed then $750 per hour is being wasted, NOT counting the work they could be doing which is going undone. NOT counting the "why did I just waste my time" de-moralization effect.

Managers have a tendency to feel comfortable when everyone is attending the meeting and available for discussion. But caution must be exercised when these meetings involve more than 4 or 5 people. People need to do their "homework" first, and bring suggestions and solutions to the meeting if at all possible, reducing the negative effects (and costs) that a large meeting can cause.

Finding Lost Family Members

This post is completely off-topic, but is one that hit home personally and I felt deserved mention.

Family members can become displaced from one another through divorces, war, moving, and traumatic events such as Katrina. What is needed is a free, electronic "bulletin board", where people can leave a "post-it" so they can be found, and likewise search for a missing loved one or friend.

I came across such a site at FindMyFamily.LastISawYou.com. After a painless, non-invasive registration, you can leave an electronic "post-it", and also search the database for any family members you may be looking for.

The downside is that the database is based upon participants who leave a message, but if the word gets out for this free service that should not be a problem.

In this day of paid services for employees, classmates, matches, etc., it's nice to find a free site doing such a noble service. I encourage you to spread the word!

Screen scraping from Business Networks

Business networks, such as LinkedIn, ZoomInfo, etc., can be a very helpful way to find professionals that may fit into your software development or management teams. LinkedIn has data that is entered by the individual, whereas ZoomInfo assembles data by scouring the 'net.

[Update April 6, 2011]

Network Grabber can now scrape pages for the LinkedIn Recruiter pages. So, if you are paying for this high level feature of LinkedIn, you can now pull the data off your screen with a click of the mouse.

However, getting information that exists in these networks into a usable format, even something as simple as an Excel spreadsheet, is not very easy. Some business networks (intentionally?) make the copy/paste process almost unusable.

Fortunately, I found a very effective tool, "Network Grabber", at www.NetworkGrabber.com. This handy tool is actually a browser, and with one click of a button allows one to copy what they have browsed into Tab or CrLf delimited format. What was taking me an hour, now takes less than 5 minutes.

My friends and colleagues can now be put into a file where I don't have to log into the network and search.

If you spend even a moderate amount of time trying to screen scrape your contacts, I suggest you give it a try. A real time saver!

Seeds of Failure

Managing vendors (and their representatives) can present its own set of challenges.

I was brought in to be Project Manager, support the IT Manager, and help oversee the replacement of their 3rd party loan package. The company in question makes loans and investments to companies that service the low income community -- loans to build housing, child care, etc. They borrow money and loan it out at a higher rate, just like a bank, but have a different business model.

The kicker was that the well known loan package had never been installed at a low income investment fund before, so they were untested in this "space". The IT Manager had never overseen this type of installation before, and the PM for the vendor was long on promises and good will, but short on delivering proof that the software could do the job.

The vendor's saleman was vague on the pricing, and when the vendor's PM came up with a quote for implementation that was near double the salesman's vagaries, there was added drama. Furthermore, the IT Manager thought the quote included the imaging module, and when it didn't they had to cough up additional money for that.

This is where I came in. One of the first things the IT Manager did was to give me the vendor PM's Microsoft Project file, with the instructions to fill it out with "more stuff".

The plan called for ONE data conversion, followed by a number of employees verifying the converted data. Then followed by workflow testing (assuming that the test scenarios could be modeled in the new system -- something that should have been done up front before selected the software package!). Then, there was ONE month of parallel testing and followed by going "live".

What I am saying here is that this project was doomed near it's inception. When I would voice my concerns, the standard answers from the vendor's PM were "I don't see any red flags" or "I think we're good". While I was skeptical and voiced as much to the IT Manager, she discounted my concerns because there was a hard go-live date and my sense of risk went against this.

As it turned out my duties were more along the lines of being an MS Project "updater", and none of my other PM skills were needed or wanted. The IT Manager and I developed a large credibility gap, and I was therefore limited in what I could do to help. There remained no real point in my staying on the project.

As I later found out, there were numerous conversions and also problems with test case scenarios. The hard go-live date was missed and there were a variety of other problems too.

As always, one reaps what they sow, and the seeds of failure were sown early-on for this project. Very unfortunate, since the the company's purpose is a noble one.

Halt the Train Wreck

At times a project is deemed to be "out of control", "a train wreck", or a "catastrophe". A time-out is required to assess the project, the team, and the management, and to see if the project can be salvaged.

While it may seem reasonable to some that project development could continue in some way while these evaluations are being made, it is best to stop the project.

Evaluation of a project disaster requires the full involvement of the key team members (stakeholders, development staff, key management), and if project development is taking place in parallel you will not get the time and focus from them required to salvage it.

Unraveling the project will require decisions that may not be pleasant. These decisions can affect the team and project significantly. Allowing the project to limp along in catastrophe mode absorbs valuable resources without any real benefit to the project, and will allow important decisions to be put off. Halting the project will hopefully "light a fire" and drive home the point that the sooner decisions are made, the sooner the project can continue.

Halting the project also sends the message that top level management is serious about the disentanglement process.