PhoneGap and offshore development lessons

I've spent the last two months working on a PhoneGap app.  In an attempt to keep momentum going even when I'm sleeping, I hired several offshore developers to assist.  Lessons:

1.  Time is not on your side

It takes time to communicate design and implementation details to a third party.  It takes most developers some time to ramp up.  (Okay---all developers.)  I set the expectation that I would be able to build this app in a month because I thought I could build it if I worked on it 24/7, but none of the resources I hired had agreed to such a schedule.  In fact, in my experience, most if not all offshore developers are working multiple contracts and will give you at best a few hours of effort per day.

2.  Good help is hard to find

How do you really know if an offshore resource is quality?  The amount they charge per hour?  Their odesk rating?  No, none of this is a true measure.  The only way to really know what an offshore developer is made of is to give them access to source, assign them a task, and see how they perform.  You can generally tell within 48 hours if you have a keeper or not.  But Lesson 1 is the downside.  I found too many that were not keepers, so too much of my time was spent hiring and testing and then retiring developers that didn't work out.

3.  One offshore trip up can cost you big

Actually I had two offshore trip-ups.  The first, I found a competent PhoneGap developer.  He went to work but didn't check in soon enough.  When he finally did I discovered that he'd changed our whole approach to development, replacing our Twitter bootstrap multi-page based layouts with jquery-mobile and a single-dom layout for the sake of gaining the page transitions.  He'd implemented new functionality, but broke the existing.  Three weeks into the project I was left with two bad options: rewrite several ajax handlers to use the new dom structure and styles and stay with the jquery-mobile approach,  or rewrite his new functions, adapting him to the (three week old) style.

Did I mention that I had told this resource explicitly NOT to add any new libraries without first getting my approval?  After struggling with the decision, I decided to stay with the new approach and fire the developer.  After all, how could I work with a developer who wouldn't follow directions?

The other trip-up?  Giving an "Apple IOS expert" access to your developer account.  Without going into details, I will only say that I spent a week trying to figure out why push notifications were not working on our production system.

4.  Don't fire your only competent developer

After a week of churning through other resources, I couldn't find anyone who was qualified to do the work who was also available.  Oh sure, I found some that said they were qualified.  And I found some that said they were available.  But in the end, they wouldn't work, or couldn't do the work.

Remember the developer I fired?  I rehired him. What else could I do?

5.  Build it yourself

This advice won't help a non-technical manager, but in my case, I faced the reality that no one else could get this done but me.  The fact that I could no longer meet my deadline was crippling for me, as this is not typical for my projects.  Frankly, I shutdown under pressure, which is one of the reasons I ordinarily front-load my projects.  Without pressure, I think carefully, methodically, and with intention.  With time pressure, I have to make bad choices and that's really hard for me to do.  I'd rather not do the job at all than to do it wrong.  But of course, this is reality, and I don't always get to control everything.  So I struggled through.

6.  CSS selectors can be evil

Developers know that css rules are used to style web pages, controlling every detail of the look and layout.  Javascript is the language that does, and javascript code controls most dynamic behaviors, control flow, api communication with the server.

CSS selectors let you chose elements in the DOM (on the page) and manipulate them one way or another.  A CSS selector is like a query tool, allowing you to grab an element by its ID, class or even its ancestors or descendants' ID and classes.

So what happens if you let a resource who doesn't really know javascript, but who is good with CSS styling, update your stylesheets?  Unless careful attention is given to any selectors, the selectors get broken, meaning bugs are introduced.  Any time the DOM is modified post-initial-development, such as the introduction of a new element in the hierarchy, there is a risk (no a probability) that javascript selectors will no longer work.   And the stylesheet rules, which are often hierarchical, may also break, so styling will be destroyed.

This means that you can't really bring a CSS resource back to do more work in the middle of the project.  In fact, you had probably better lock them out once the initial styling is done.

A good best practice for the future:  Lock down the DOM.  Tell your resources it simply can't change without your approval.

7.  Too many cooks in the kitchen

Even when working with competent developers, it's really difficult to collaborate on a jquery-mobile project.  All pages are embedded in single DOM, leading to CSS rules that are more complex than would exist with smaller, dedicated pages.  It's too easy for developers to break each-other's CSS rules.  Some best practices for my future projects:

• With CSS Selectors, prefer IDs to Classes, except in cases where a Class is the only solution (such as selecting every matching element). $(".wrapper .red .spanky .britches") is more likely to become invalid as development progresses than $("#the_britches_element").
• Commit to the completion of HTML, CSS and layout before introducing the javascript and logic
• Consider using a templating engine to reduce code duplication

8.  You can find a good offshore resource

I found a really great PSD-to-HTML resource last year and I really enjoy working with him.  He's responsive.  He does a good job.  He replies quickly.  He does what he says he's going to do.  Going it alone is not the best approach.  It should be possible to proceed as a team, and I'll continue in my efforts to build an effective one.  But throwing together a team to complete a project within one month?  Probably too ambitious.