./databyte

The recent fuss over Sparrow reminds me of something a friend was doing the other day on Pinterest. She was copying and pasting the images out of the site into a Word document. Mind you she hates Word. I told her she could pin it to her own board and her response was: “Why bother? They’ll just close the site down in a couple years and I’ll lose everything. This way, I know I’ll have it.”

Unfortunately this proposal doesn’t work for highly trafficked sites that require a team of dedicated engineers to keep it operating but it would work for Sparrow and a number of other useful applications that have disappeared.

The Open Source Promise.

The company promises that the product Foo will be open sourced should the company be acquired or shutdown and stop maintaining the product.

The benefits to the customer are obvious. We still get to use the software and help keep it going. The benefits to the company are numerous as well. It helps the company brand as their product gains popularity. It bolsters the parent company’s brand as they acquire their talent. There’s little need to worry about the brand since the company was going to kill it anyway but if lawyers are involved, it could easily be ripped out and left for the community to rebrand it as part of the transition plan.

I would love to see a variation of this license available online but we need baby steps.

So if you’re looking to quell some of our fears or shine a better light on your new corporate overlords, put up an Open Source Promise.

I found that sometimes even good developers lock up when given the “code on a whiteboard” option. It makes sense to do a basic FizzBuzz exercise or talk through an architecture design but writing outside of an editor is odd for anyone unless they’re a professional interviewee.

If possible, I jump into a pairing opportunity. A few hours or a day of pairing on something can show a lot of details.

• How do they approach a code or design problem?
• Do they TDD?
• How quick are they to backtrack on a bad idea without investing too much time on it?
• What tools are they already comfortable with or experienced with?

It’s always interesting to see someone’s desktop and their setup. Or to see first hand how they utilize their time.

Here’s my recommendation for technical interviews. At this point, they should have spoken to someone for at least 1 hour attempting to assess their technical capabilities but usually it’s 30 mins talking about your company and 30 mins talking about the candidate. Before interviewing, come up several applications to design. The ideas can be fun and interesting down to ETL and data scrubbing. For instance:

• The Game of Life
• A service to grab music artist information from 4 different APIs
• Parsing some data from NYC Open Data

The long form technical interview will take 2-3 hours. Two people spend 30-45 mins each going over their own questions covering problem solving, language preferences, details on implementations in the past, thoughts on this or that, etc. Any or all of which could’ve been their co-worker’s work or their mentor’s preferences. Then ask them to sketch out, on paper or just out-loud, a solution to one of the problems from above.

In the last hour, you then ask them to build one of the solutions. By this time, they have already walked through two of the designs. They don’t have to finish, they just have to start and show off enough. This is where pairing comes into play. Work the problem with them. Let them drive and do most of the work, nudge them when needed. You’ll be a poor pair partner this way but at least you’ll be there to answer questions without letting the candidate spin. Which is one of the essential benefits to pairing. Another key insight will be in how they work the problem, discuss the design and implement the code.

Another technique I encourage is to setup the candidate as a contractor for 8 hours (1099). If they can take an entire day off of their current job to be your pair partner, great. If they can’t, how does 2 hours every night during the week or 4 hours over two days? If you’re going to be sitting next to this person for years to come, you should at least date a little before getting hitched.

TL;DR

Heroku’s uptime for June under their rules is 99.28% but really it’s 96.25%.

I like how Heroku added an info icon which links to a page explaining their modified uptime numbers. They added in the number of running applications affected in each outage. There are a few problems with this.

Firstly, idle applications do not count but unfortunately during many of these outages - idle applications can’t come online. I don’t believe I’ve heard of a service that said our site’s availability was 100% because you weren’t logged in right before the event happened. But for Bob who was logged in at the time, his uptime was 99.28%. Additionally I’ve not seen uptime reports take into consideration the number of accounts.

Secondly, how do they count the number of applications affected and how are they sure? During last month’s outage, I had several clients have their sites available but degraded and slow. Some sites were available one minute, gone the next and then back again. How do they count these?

At another company I recently worked with, we had several Heroku applications working in tandem in an SOA configuration. Such an event may have affected one application in some manner which would then affect the entire system. There’s no way to calculate that either.

So Heroku lists their uptime for June as 99.28% with all these new considerations in place which is still… pretty bad.

I’ll give Heroku a pass on Varnish being down for an hour since Cedar is the default but I won’t give them the API being offline for 4m as “Development” only because many DevOps operations require the use of the API. If you can’t scale up under load, then you have a production level problem.

The uptime for production only outages for June is 96.25%. Not 99.28%. This is based on number of minutes in the month and number of minutes production was down. Simple.

Recommendation to Heroku, if the numbers are hard to understand then get rid of them. AWS doesn’t have an uptime percentage on their status page. Trust us, we know June was a bad month for you.

Too bad Heroku doesn’t have a good view of what June looked like. Oh wait, I do.