Category: Business

Record Development Meetings with Hangouts On Air

At Oasis Digital, our project teams coordinate in numerous ways, sometimes by meeting “live”. At these meetings we discuss, we plan, we model, we code, we review. For teams/projects where everyone is physically present at headquarters, this is readily done by plugging in to a large TV re-purposed as a computer monitor. (Proposed bumper sticker: “My other monitor is a 60 inch Samsung”.)

For some teams and projects, though, not everyone is at our St. Louis office. Some of our developers are around the US, and occasionally projects include developers around the world. Therefore, some of our development meetings take place online, using a variety of meeting tools. Mostly these meetings are useful only at the moment they occur, but it is useful to record them for developers who are unable to attend “live”.

There are countless tools to choose from. We have had particularly good results with Google Hangouts. Unfortunately normal Hangouts has no recording feature – the recording capability is available only in the form of “Hangsout On Air”, which is more typically used to “broadcast” an online meeting. Google Apps customers, though, can use Hangouts on Air, decline to broadcast to anyone at all, then share the recording privately.

The process is not obvious. Here is how to use Hangouts On Air to privately record and share online meetings:

  1. Consider performing all of these steps in a dedicated browser. For example, use Chrome for Hangouts, while using Firefox for other browsing. This reduces the opportunity for Hangouts (which is irritatingly bound to the browser) to interfere with other use of your computer.
  2. Log in to YouTube. Use the Google account selector in the upper right to select your company Google Apps account, if you are logged in an more than one account.
  3. If you don’t already have a YouTube “Channel”, which you probably don’t, click to create one. It is harmless, since for this Hangouts On Air purpose you don’t need to every actually publish anything to your “channel”.
  4. Click “Video Manager”. The button for this is not in the most obvious place (the left navigation), rather it is along the top, and small.
  5. Click Live Events.
  6. Click to create a new live event.
  7. Give your meeting event a name.
  8. The description, keywords, etc. do not matter, since you won’t be publishing.
  9. Adjust the setting to make it Private. This is a vital step, don’t miss it.
  10. Don’t share it with anyone yet. That comes later.
  11. Choose the default Quick settings, there is nothing important to adjust in the Custom settings.
  12. Click to start the Hangout On Air. This will launch the same Hangouts app as any other Hangout – almost. As of December 2014, the features for Hangouts on Air are somewhat behind the normals Hangouts app in features and screen layout.
  13. Click the invitation/add button in the Hangouts controls at the top of the Hangouts window.
  14. Copy the link. Paste it in group chat so that other developers (meeting attendees) can join.
  15. Wait for everyone to get in the meeting. Adjust microphones, webcams, speakere, etc.
  16. Remind everyone to turn on their webcam and keep it on if possible. This provides a much better experience for anyone watching the video later – they get more of a sense of having “been there” for the meeting.
  17. Discuss anything that isn’t part of the project in question, etc. while waiting for everyone to be ready.
  18. Click Start Broadcast. This will start the “broadcast” to noone (because this HoA is private and not shared with anyone), and more importantly, start the recording.
  19. During the meeting, remember that whatever is visible in the Hangouts app window, will be recorded. Adjust this regularly to keep it relevant to the discussion. Often the default behavior of switching to whoever is speaking, works well.
  20. Remember that Hangouts On Air recordings are limited to pseudo-high-def, “720p”. Keep screen share window sizes moderate, so that text can be easily read by others in the meeting and on the recording. Sharing a full-screen at 1920×1080 or higher resolution will yield unreadable results.
  21. When the meeting is done, Click Stop Broadcast.
  22. Back in the Youtube Video manager, paste in the email addresses of those with whom the recording should be shared.
  23. Don’t trust Google/YouTube to maintain privacy settings over the long term – leave the recording there until it has outlived its usefulness (a week or so in a typical project, maybe longer in a slow-paced project) then delete it.

Ouch, a 22-step process. That is the price of using Hangouts On Air in for an atypical purpose. The payoffs:

  • HoA works well across all major platforms, including Windows, Mac, Linux, Android, Chromebook, and more. This is the hardest thing to replace, many other meeting tools don’t come close.
  • The recording is immediately available privately on YouTube, all transcoding and hosting is seamless and effortless.
  • Google / YouTube is infinitely scalable, for all practical purposes.
  • No cost, for either the tools or the hosting.
  • Part of software (Chrome) that most developers have already installed.

 

Bits are Free, People are Valuable

A few days ago, I caught myself thinking about whether to save some images and video; whether the likely future value of those megabytes would be greater or lesser than the cost of storage. This is a sort of thought that was important and valuable… a couple of decades ago.

Bits are Free

Today, and at least for the last decade, bits are so absurdly cheap that they can be considered free, compared to the time and energy of people. Storing gigabytes or terabytes because they might come in handy is not just for government agencies, it makes sense for all of us in our daily work.

Waste bits to save time.

Waste bits to help people.

People matter, bits are free.

Bits are Free at Work

Here are some ways I waste bits at work:

  • We often gather a few people working on project to meet or code together; it is very easy to start a video or screen video recording of the work. That recording can then be shared with anyone on the project who wasn’t present.
  • We record screenshots or videos of the future in progress, and send it to a customer. Yes, we could wait and present to them “live” using WebEx or whatever. But it is cheaper to waste the bits and conserve human coordination effort.
  • If I have something complex to explain to someone, I can do it in person, and I can do it on the phone, and I can write lots of text. But if I already know them well enough to partly anticipate their questions, I will start a video recording and explain something using voice and white board. The bits are cheaper than the coordination to work “live”. The bits are cheaper than asking them to figure it out themselves.
  • Driving down the road, it is unsafe to text, or read, or write, or (I am looking at you, morning commuters…) apply makeup. But while the numbers are unclear, we have a broad assumption that merely talking with someone while driving down the road is OK. I sometimes make use of traffic time, and burn some bits, by recording audio about some problem to be solved or other matter. The bits are free, who cares if this uses 1000x as much data as sending an email?

Wasting bits can grow somewhat extreme. In the first example above, I described a screen video of developers working together, recorded for the benefit from other developers. You might imagine this as a high-ceremony process, done on important occasions about important code. But bits are free – so we sometimes record such video even if no developer will ever pay attention to it – the value is there even if just one developer maybe lets it play in the background while they work on something else – much like by working in the same room as other people, it is common to pick up some important bit in the background. If one developer learns one small thing to make their work better, that is more valuable than 400 MB of video storage space.

Bits are Free at Home

Here are some ways I waste bits at home:

  • When I take photographs, I take a lot of photographs. One might come in handy. Who cares if 95% of them are bad and 90% of them are useless?
  • Why do cameras have settings other than maximum resolution? Bits are free.
  • Nearly 100% of paperwork I get in the mail, other than marketing, I scan, OCR, and keep in a searchable archive. The disk space for this costs almost nothing. The time saved deciding whether to keep each item, and how to file each item, is irreplaceable. I probably only ever look at 10% of what is scanned, but who cares?
  • If my kids are doing something even vaguely interesting, I try hard to remember to take photos and record video. Looking back at when they were very young, snippets of video we have (from before every phone had a decent video camera) are priceless. I can’t reach back and record more of those, but I can easily record things now that might be fun in the future. Who cares if 95% of that video no-one ever looks at? If I ever need to go through it, I can do it then. The storage space in the meantime doesn’t matter.
  • If I need to look at a model number, serial number, etc. of anything around the house, I snap a photo of it. Then I can look back at the photo anytime from anywhere. Yes, it is absurd to store 3,000,000,000 bytes of JPG rather than 20 bytes of serial number. But they both round to zero.

How Free Can Bits Get?

I expect this tradeoff will shift even more exponentially in the future. In a couple of decades, perhaps:

  • We will record 5 petabyte ultra beyond-HD holographic recordings of insignificant activities just in case someone wants to watch them.
  • We will run video and audio recording of our lives 24 x 7, to be indexed just in case anyone ever wants to look back at it.
  • Future cameras won’t even come with an on-off switch, and will instead record continuously for the lifetime of the camera.

 

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
play-sharp-fill

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.