Our Interns Built a Mobile Web App, Here is Their Story

This summer, we hired three interns to build a mobile web application and learn a bunch in the process. Here is their story, in video form:

video

If you don’t have Flash installed (and thus don’t see the video above), you can try this direct link to the video. It plays well on most platforms (including an iPad).

It is also available on YouTube.

Oasis Digital 2012 Summer Internships – Mobile, Tablet, Web

Application Deadline: May 15, 2012.

Applications are now closed.

It’s almost time for our Summer 2012 internship program. You might want to look back to our 2011 program, or our inspiration, the Fog Creek program. Interns at Oasis Digital work on serious, complex projects, though the work is generally exploratory in nature (rather than part of our enterprise development work for customers). Interns write software, test software, write about software, etc. The purpose of the work is to educate and enlighten the interns, and also create something useful to Oasis Digital and its customers.

Who?

We plan to hire two or three student interns.

Unlike some programs, ours is for high school students, or recent graduates about to enter college.

How Long?

The work will last about 10 weeks, from the first week of June through early August. Interns should expect to work around 30 hrs per week, though only a small portion of that will be on-site in-person. Other than a few fixed meetings per week, your schedule will be flexible.

We can adjust the dates if needed, to accomodate college start dates, family vacations, and so on.

Where?

Interns will meet at the Oasis Digital office two or three times each week. Our office is in Chesterfield, MO. Therefore, interns must live in the St. Louis metro area and have transportation available.

At these office sessions, we’ll all work together, and interns will learn from various Oasis Digital developers. Outside of that, interns will work alone, and meet to work together, for a total of around 30 hours per week.

Does it Pay?

Yes, these are paid internships. Each intern will earn about $2200 for a full summer of work.

In additional, our meetings will be scheduled to include a company-paid lunch a couple of times each week.

What Will We Build?

The project for this summer will be a workflow management system, with web and mobile-app (smartphone, tablet) interfaces.

Interns (with help from Oasis Digital staff) will create an end-to-end system:

  1. Database Schema
  2. Server / backend services
  3. Web client application
  4. Mobile (native or HTML5) app
  5. Tablet (native or HTML5) app
  6. Document and deploy all of the above

The schedule goal is to develop an extremely simple version of the above, and “ship” it in working condition, halfway through the summer. Then with the rest of the summer, add interesting features, platforms, polish, etc. GPS, mapping, photo support, multitouch clever interfaces, anything is possible.

More importantly than what we will build, is what everyone will learn. Expect to learn more in this summer than you would in many classes.

What Language?

The exact toolset will be worked out by the interns, and may include:

  • JavaScript
  • Node
  • JQuery and similar libraries
  • Java
  • Clojure
  • Git / Github
  • HTML (including HTML5)
  • PostgreSQL or MySQL
  • Linux, Windows, OSX
  • iOS, Android
  • Various other open source tools and libraries

Requirements

  • Excellent command of written and spoken English
  • Currently enrolled in high school, or just graduated.
  • Top grades or a track record of success
  • Permanent legal right to work in the United States
  • Great (for your age) computer programming skills
  • Live in the St. Louis MO metro area
  • A computer available to work on, when you’re not at the office

How Do I Apply?

Apply via our job application page, not by email or phone. This is the same mechanism we use for hiring non-interns, so it is perhaps overly complex; we expect intern applicants to have a short, one-page resume listing interests and personal projects, not professional work.

Please apply by May 15, 2012. 

 

Hire a RAIT: Redundant Array of Independent Teams

Life is Risk

Whenever you hire out work, either to a person, to a team, or to a company, there are risks. These risks can easily prevent the work from being completed, and even more easily prevent it from being completed on time. (I’m thinking mostly of software development work as I write this, but most of this applies to other domains as well.)

What could go wrong with the person/team/company you hire?

  • They get distracted by family or personal issues.
  • They turn out to not be as qualified or capable as they appeared.
  • They leave for better work. Sure, you might have a contract requiring them to finish, but your lawsuit won’t get the work done on time.
  • They turn out to not be as interested in your work as they first appeared.
  • They start with an approach which, while initially appearing wise, turns out to be poorly suited.
  • Illness or injury.

Of course you should carefully interview and check reputations to avert some of these risks, but you cannot make them all go away. You don’t always truly know who is good, who will produce. You can only estimate, with varying levels of accuracy. The future is unavoidably unknown and uncertain.

But you still want the work done, sufficiently well and sufficently soon. Or at least I do.

Redundancy Reduces Risk

A few years ago I stumbled across a way to attack many of these risks with the same, simple approach: hire N people or teams in parallel to separately attack the same work. I sometimes call this a RAIT, a Redundant Array of Independent Teams. Both the team size (one person or many), and the number of teams (N) can vary. Think of the normal practice of hiring a single person or single team as a degenerate case of RAIT with N=1.

To make RAIT practical, you need a hiring and management approach that uses your time (as the hirer) very efficiently. The key to efficiency here is to avoid doing things N times (once per team); rather, do them once, and broadcast to all N teams. For example, minimize cases where you answer developer questions in a one-off way. If you get asked a question by phone, IM, or email, answer it by adding information to a document or wiki; publish the document or wiki to all N teams. If you don’t have a publishing system or wiki technology in hand, in many cases simply using a shared Google Document is sufficient.

There are plenty of variations on the RAIT theme. For example, you might keep the teams completely isolated in terms of their interim work; this would minimize the risk that one teams’ bad ideas will contaminate the others. Or you might pass their work back and forth from time to time, since this would reduce duplicated effort (and thus cost) and speed up completion.

Another variation is to start with N teams, then incrementally trim back to a single team. For example, consider a project that will take 10 weeks to complete. You could start with three concurrent efforts. After one week, drop one of the efforts – whichever has made the least progress. After three weeks, again drop whichever team has made the least progress, leaving a single team to work all 10 weeks. As you can see in the illustration below, the total cost of this approach is 14 team-weeks of work.

How might you think about that 14 team-weeks of effort/cost?

  1. It is a 40% increase in cost over picking the right team the first time. If you can see the future, you don’t need RAIT.
  2. It is a 50% decrease compared to paying one team for 10 weeks, realizing they won’t produce, then paying another team for 10 more weeks.
  3. If you hired only one team, which doesn’t deliver on time, you might miss a market opportunity.

Still, isn’t this an obvious waste of money?

To understand the motivation here, you must first understand (and accept) that no matter how amazing your management, purchasing, and contracting skills, there remains a significant random element in the results of any non-trivial project. There is a range of possibilities, a probability function describing the likelihood with which the project will be done as a function of time.

RAIT is not about minimizing best-case cost. It is about maximizing the probability of timely, successful delivery:

  • To reduce the risk of whether your project will be delivered.
  • To reduce the risk of whether your project will be delivered on time.
  • To increase your aggregate experience (as you learn from multple teams) faster.
  • To enable bolder exploration of alternative approaches to the work.

What projects are best suited for RAIT?

Smaller projects have a lower absolute cost of duplicate efforts, so for these it is easier to consider some cost duplication. RAIT is especially well suited when hiring out work to be done “out there” by people scattered around the internet and around the world, because the risk of some of the teams/people not engaging effectively in the work is typically higher.

Very important projects justify the higher expense of RAIT. You could think of high-profile, big-dollar government technologies development programs as an example of RAIT: a government will sometimes pay two firms to developing different designs of working prototype aircraft, then choose only one of them for volume production. For a smaller-scale example, consider the notion of producing an iPhone app or Flash game for an upcoming event, where missing the date means getting no value at all for your efforts.

Thanks to David McNeil for reviewing a draft of this.

In the Arena

Almost every day at some point I wander over to Hacker News, which has some great discussion, along with some less great discussion, among people pursuing or aspiring to pursue a software startup or similar business. Likewise with local events (like ITEN STL offers), and even more so the Business of Software conference earlier this month. (experiences)

I used to have a software product business myself, a vertical market SaaS firm. Now that I’ve been out of that for over a year, the thing I miss most is the feeling of being “in the arena”, of having a speculative product out there for people to buy. To be out there is both terrifying and exhilarating. I have heard it said that there are “product people” and “consulting people”, and looking back it is clear to me that I am mostly in the Product category.

Unlike some product people (like Amy Hoy, whom I admire greatly!) I don’t think it’s necessary to swear off one thing to do the other. Consulting (building software for clients) is very satisfying, especially when working with a team of great people (and a group of very competent customers) like we have at Oasis Digital.

So while I’m going to keep building software for other people, I’m also going to go back to the marketplace with speculative products. This time it will be products in the plural, some subset of:

  • Web/SaaS software
  • iPad software
  • iPhone / iPod Touch software
  • Android software (by year-end the stores will be piled high with Android tablets)
  • Or possibly HTML5/etc software to address all of the above
  • Backend / data / system management software
  • Or even, possibly, locally installed desktop software

I apologize for the vagueness of this list; but I agree with Derek Sivers about keeping one’s specific goals to oneself so my voluminous and tedious notes on exactly what products to offer, will remain offline.

Apple is Building a Bigger Footprint

I’ve seen a lot of people writing (whining?) about being unimpressed by some of the new Apple products/features announced at their event this week. These folks are missing Apple’s strategy. Several of Apple’s new gizmos are laying a foundation and pointing down an obvious path for their products:

iTunes-Ping Social Network

It doesn’t integrate with other social networks, and the initial content on there (from what I’ve heard, I didn’t even bother to look) is weak, consisting mostly of some well-known musicians who (shockingly!) think you should buy their music. None of this matters. If Ping v1 gets Apple some incremental sales in the iTunes store, it’s a win. Apple has an enormous audience, so inevitably Ping will get some level of community, and with that in place Apple can bring out a v2 in which they add integration, support in all of their devices, etc.

Apple TV

The 720 resolution is a disappointment, and I find the lack of a digital audio output rather surprising. No apps. It doesn’t compare well on technical features, with some similar products already out there.

But it’s a whizbang, very friendly Apple device $99! It will probably sell in big numbers, to many millions of consumers who haven’t (and won’t ever) hear of the similar products from lesser-known firms. Once there is a big user base out there, Apple can announce Apps and other features for Apple TV, with enormous fanfare and day-1 sales volume.

iPod Nano with multi-touch

This doesn’t have apps yet either; and similarly, the foundation is clearly there. Apple can add some form of Nano Apps in the future, again with an installed base already in place ready to start buying apps (in volume) on day 1.

iPad Multitasking

As a power user and developer, I find it a bit annoying that the iPad, a powerful computer launched in 2010, didn’t ship with multitasking. Yet I’m very happy with the device anyway, and it didn’t stop Apple from selling a billion dollars’ worth of them in a few months. Adding multitasking for free in November is a nice (small) step forward, plenty good enough for a mid-cycle update.

Winning Big

Apple isn’t merely trying to win today. They are trying to win big.

Sorry, Not a Fanboy

But am I a fan of all this?

  • As a user, yes. I enjoy Apple’s products. I am typing this on a MacBook Pro, with an iPad sitting nearby.
  • As a developer, I am not a fan of the increasingly closed ecosystem they are building. It reminds me ominously of the first generation of home computers, and current gaming systems, where the manufacturer interposes themselves in every financial transaction forever. That approach lost to an open market back in the 1980, I hope it does not take over the PC world ever again.
  • In addition, the closed ecosystem excludes many possible applications that would be very useful to our customers.
  • As a business aficionado, I nod approvingly at their strategy and execution prowess.

Update: I’m not the only one who thinks Ping will make Apple a lot of money, regardless of its merit.