Thursday, May 22, 2008

Netflix Player by Roku

I was really thrilled to hear today that people buying Roku's new set-top box for the Netflix Watch Instantly service is backordered by 10 days. Well, not so thrilled since I just ordered mine, but happy that the device is so popular.

Friday, May 16, 2008

Bacterially Generated Buckytubes

I'm a fan of the concept of a space elevator. I'd love to be able to see this technology envisioned by Arthur Clarke in the 70's become reality some time before I die. One of the biggest obstacles to the creation of the a space elevator is a breakthrough in the material science necessary to build a tether.

There are some promising bits of work being done on carbon fiber and buckytubes, but the last I heard, there were scaling problems. Sure, we can generate a fiber a few millimeters long that's strong enough, but getting from there to 100,000km is still a really big leap.

What if someone genetically engineered a bacteria that had some chlorophyll in it and had a predilection for growing a buckytube tail? Now you stick a vat in the sunlight and start pulling the thread... Voila! space elevator tether!

Monday, May 05, 2008

Did I mention that I was hiring?

I'm currently looking for three different people to fill three different jobs here at Netflix?. The first is a QA engineer for our Instant Viewing on the PC client. The second is a QA Engineer for the Netflix API team. The third is a QA Engineer for the Customer Account team.

While each of those job descriptions has a list of technical requirements, I need someone (three someones) who can understand the why of testing just as much as they understand the how of testing. A particular tool in your toolbox isn't as important as knowing how to select the right tool for the job (or even learn a new one). Likewise, having demonstrated prior experience in knowing where to apply your tools for the greatest effect is more important than any particular bit of prior experience with a particular technology.

I've been toying with a mission statement for my group:

Economically review changes in order to prevent, detect and mitigate impaired customer experiences.

If this somehow speaks to you, I'd love to hear from you what you think it means. I might want you to apply yourself to that mission.

Sunday, May 04, 2008

Software Plasticity and Risk: The Search

After writing yesterday's post, I decided that it might be a good idea to take a look and see if anyone else was using plasticity in the sense that I was trying to use it, or if there was an already established notion of plasticity that I'd be swimming upstream against.

Again, my notion of plasticity is: how changeable is the system in question balanced against the cumulative risk to the business of the change itself and the risk to the business of actually making the changes.

I found a couple links via Google. The first was from a paper submitted to a 2004 conference in Hamburg, Germany. It discussed the concept of a new widget type, "the comet", that would adapt its function based on the execution context. Not exactly what I was after. The second was a link to the same paper from a different source. Then, surprisingly, the third entry was my blog post from yesterday.

In the fourth position, was a blog page that was just a click through to the real article which was actually discussing the use of aspect oriented programming (AOP) and the concept of software plasticity. In reviewing it, this appeared to be more of a discussion of how to apply AOP as a debugging tool, rather than how to build and maintain a system in the context of keeping a business running and satisfying customers.

After that it seemed to get a little random, except for a link to a PDF on UI plasticity. The article referenced by the top link continued to show up an awful lot from a bunch of different sources as well. I took a look at Yahoo search and Dogpile. Came up with the same set of stuff.

From this survey, it seems like there hasn't really been a lot of thinking published on the web about the development effects of the plastic nature of software, and especially when evaluating plasticity within the context of business risk.

I guess I'll keep flogging it and see if anything useful comes of it.

Friday, May 02, 2008

Software Plasticity and Risk

I've been toying with the concept of plasticity with respect to software. I've also been thinking about the software development process and how plasticity relates to the risks introduced by making changes to software.

Think about using a scale from 1 to 10 to describe how plastic a software product is. A one (the least plastic software product) would be a consumer electronics device where the software is embedded and it's impossible to update the software. Examples would include a portable DVD player or a digital clock radio. A ten would be something like a website (perhaps like the Netflix website or Instant Viewing PC client -- and I happen to be hiring one or two QA Engineers), where if there are defects discovered, they can be fixed quickly by pushing new code to the servers, and instantly, all users get the new code.

Then, think about the risks you run by making changes. My canonical examples to contrast the risk of changes usually go something like this:

1. We're updating the encryption key that we use to encrypt the credit cards for our members. We test this very thoroughly. The risks to the business are very large if there's a screwup and the benefits of avoiding screwups are equally large. Therefore, it makes a lot of sense to invest a lot in testing.

2. We're modifying how we format the pages for different genres of movies so that boxshots are right aligned instead of left aligned. Not a lot of risk for damaging the business there. We may not even do any formal QA and leave it up to the UI engineers to make sure they get that one right.

I haven't worked out the details yet for measuring risk vs. plasticity, but I imagine some kind of matrix with plasticity across the top and different software components down the side. The intersection of each row and column would have some metric that boils down the cost to fix, the cost to deploy, the risk of change and the risk to the business. Then, during the course of normal development, or in the case of an emergency, evaluate the proposed change on those four dimensions to come up the metric for that change and compare to the matrix for where the change lies. If there's a net positive risk/reward, do the change immediately in the case of a fix to production. Likewise, if it's part of the normal development cycle, then if there's a positive risk/reward, allocate the QA resources to fully test. If there's not adequate reward for testing, or the risk to the business is low enough, dedicate the limited QA resources elsewhere in that push cycle.