The Future of Cable-TV

There's a bit of a discussion going on between Mark Cuban and Avner Ronen. It started with someone writing an article about boxee, the company that Avner heads.

Mark seemed to take exception to the article, and posted, "Why Do Internet People Think Content People Are Stupid?" Avner then followed up on his blog.

I've been thinking about Cable and Broadcast TV for a while. I find myself agreeing with Avner, that the Internet will allow customers to have a la carte access to shows and channels.

First off, why would this happen? We only need to look at PVRs to see where it is going. PVRs are changing the relationship between broadcast networks, content creators and viewers. Currently, a PVR changes how a viewer makes use of the TV network. They can watch any show they are interested in, regardless of when it was broadcast, or even if they know it is being broadcast. People with PVRs timeshift TV shows, frequently watching a show up to a week after broadcast. This change in viewing habits is showing up in the TV show's ratings, with some shows seeing a drop of up over 30% viewership as their viewers record it for later viewing.

What happens when the majority of your customers have PVRs? They no longer watch "whatever is on". They will watch the shows that they want to watch, when they want to watch them. The broadcast schedule becomes less important. In fact, it doesn't matter when the show is broadcast anymore. Your viewers will automatically follow the show through scheduling changes.

Some consultants say that people will still want to watch the show during the broadcast slot so that they can talk about it the next day at work. That is true, there is some pressure to watch a show as it comes out, but it doesn't need to be watched immediately. It can be watched just as easily +1,+2,+6 hours later. The person could even elect to watch the show the next morning over coffee or on the way to work on the train.

So, if the timeslot doesn't matter, what does that do to a broadcast network? Frankly, it turns them into two things. First and foremost, they are aggregators. They decide what it is that you are going to watch. Second, they are a very efficient one to many data network. Because of their sunk costs in the form of spectrum and transmitters they are able to deliver content to homes across the world cheaply.

Now, remember, in the world of the PVR, it doesn't matter when a show is broadcast - it'll be found and recorded. This lowers the value represented by prime-time slots. Everyone is watching TV at that time, but it isn't needed to show them pre-recorded content. It also increases the value of the 2-6AM slots. The time when a broadcaster would usually send out a test-signal or infomercials are now perfectly positioned to show syndicated content.

Remember, it's all about feeding the PVR. You want to fill their viewing hours with _your_ content, not the other guy's.

So, we're not in a world where insanely popular shows are broadcast to people's PVRs at 2AM on a Monday morning. Just in case you think this is crazy, this is exactly how bittorrent works with background downloaders like TED (torrent episode downloader). TV shows show up on the pirate networks in the middle of the night, and are available for watching on your local PVR a couple of hours later.

So, now that they're feeding your PVR, what happens next? Aggregation. The networks provide aggregation and editing services. They are tastemakers. The only problem? They demonstrate this taste through their line-up and schedule. As I've already shown, the schedule is unimportant - people use PVRs. That leaves only the line-up. Those "up-next" teasers for the next show? Of little value - the viewer can't watch the next show! So, the line-up also becomes unimportant. There is no way to package shows to make viewers more "sticky". They will choose shows from networks a la carte. Again, we can already see this behaviour - both on PVRs, and bittorrent. There are also better "tastemakers" than networks. They're called bloggers. There are a lot more of them, they are the reviewers of the Internet age. Even better, they are perceived as more trustworthy, because they don't review things for a living. True "tastemaking".

In the world of the PVR, syndication is dead. In the world of 500 channels, how many versions of CBS do you need? How many times a day do you need to watch the same episode of "The Simpsons"? If your viewers have a PVR, the answer is you only need 1 instance. All those cable networks that are syndicating your shows to fill in their schedules? If you put those shows on your own network, with your own ads, you can have that revenue too.

So, the value of syndication has just collapsed. There's only room for one copy of each episode per week (perhaps even per year). All that revenue broadcasters get from cable companies for retransmitting their channels? Gone - the cable company only needs one, and they'll take the local one - they can frequently get that for free.

Let's recap. We've killed the schedule, aggregation and syndication. We have just turned a local TV broadcaster into a broadband pipe that specialises in delivery of video and audio content supported by local advertising.

Does that sound familiar? It should. It's an ISP running a rewriting HTTP proxy, that inserts advertisements into pages that its customers view.

At that point, the model shifts. Content producers sell their own advertisements and purchase time on the broadcast networks. This is how I see it proceeding:

1. Content producers sell their own advertisements.
2. They put their back catalog up on the Internet at VoD.
3. They make the content available on a P2P network.
4. In markets where they have significant penetration, they purchase time from the local broadcasters, and feed that information to their customers.

Now that would be an interesting synergy. You watch a show on Hulu through Boxee. When you are finished, up pops a dialog box "Would you like to schedule this show for recording in your area?". If you select yes, it instructs your local PVR to record that show the next time it comes around.

All of a sudden, there is a continuous flow between Internet VoD, P2P and OTA (or cable) broadcast. Each with their own strengths.

That'll be cool.

New Zealand S92A

Just to make sure that my stance isn't lost now that the blackout's been lifted.

I would like to see several changes to the TCF, including the right to see the evidence of your accusers.

Holy Cow

Wow, the price plans are changing. Even the prepaid plans are getting into the whole "flat rate" thing. I love the idea of a plan where if you don't use the phone, you aren't charged for the plan. The addition of unlimited on-net calling? Perfect.

Verizon prepaid pricing changes coming February 11th

(from Engadget Mobile)

Risk Management, are you getting your money's worth?

For the first time in the better part of a decade, I'm tech lead on a new project for my current employer. For the intervening years I've been working for other employers, other projects.... I wasn't slacking, honest!

Anyways, it gives me a perfect opportunity to compare and contrast the organization of 10 years ago with today.

Holy Cow! It takes them way to long to start up a project. They spend too long deciding what to do, and not enough time actually doing it. Of course, this is all in the name of "risk mitigation".

I'm finding it both extremely frustrating and hilarious. It makes me want to throw things. The company is going to spend well over 30k to make sure that the 150k they spend on the project is a success. Even before writing the SRS. They are going to spend 30k writing a Product Concept Document, Project Definition Workshops, Project Initiation Gate Meeting, and a Product Scoping Document with estimates. I'm even willing to bet that I am underestimating how much they've spent on this.

The funny thing? All that work will be thrown out as soon as the SRS is written.

The next shock was the testing cost. For every day of development, there is a day of testing, more risk mitigation. Then there's another day added for "overhead". So, that small 100 day project? It's actually 300 days.

So, I looked at it from a math point of view. First the project budget:

1. Pre-SRS work - 45k
2. SRS - 45k
3. Development effort - 100k
4. Testing effort - 100k
5. Management overhead - 100k

Total Project cost: 390k
Risk of complete failure: 10%

Even worse, the calendar time and effort are unrelated. The calendar time for steps 1+2, 3, 4 are all the same.

Now, let's have a look at a riskier way of doing it:

1. Pre-SRS work - 15k
2. SRS - 7k
3. Development effort - 75k
4. Testing effort - 50k
5. Management overhead - 50k

Total Project cost: 197k
Risk of complete failure: 50%

We've gotten rid of all of the risk mitigation. Not only that, we've shrunk the time in steps 1+2 by 75%! That's a huge time to market win.

Let's see if the risk reward makes sense.

The cost of a failure is 50% (odds of failure) * the cost of the project:

  Risky Way: 197k * 0.5 = 95k
  Safe Way: 390k * 0.1 = 39k

Therefore, the amortized cost of a project using the:

  Risky Way: 197k + 95k = 292k
  Safe Way:  390k + 39k = 429k

What failure rate would be needed to justify the extra cost? 70%? 80%? 90%? To justify the extra money spent (assuming 0% the safe way), the failure rate would have to be:

390k - 197k
----------- = 97%
   197k

Failure is the cost of total failure, as in the project has to be thrown away and started over.

Add in the time to market benefits (on the order of 30% for these assumptions), and it starts to look pretty convincing.

Everyone wonders why so many businesses are CMM level 0/1. Have you considered that they might actually be right?

Prepaid is Dead, redux.

I just saw this in the news today:

Boost sees $50 unlimited plan battling Leap, Metro

Unlimited calling and texting for US$50/month. It's a race to the bottom with all-you-can-eat plans.

If you're charging per minute, per sms, per byte, the question is "why?". Save yourself a lot of money and quit billing for the core service! That Intec Billing Engine you're thinking of buying? Get rid of it, or use it for something other than charging for calls.

Adding value?

Ask yourself, "Can I be replaced with a shell script?" Specifically:

 % yes 'No'

Then ask yourself, "What value am I adding?"

Google Chrome, a Contrarian View.

I read the comic about Google Chrome. I love the architecture! We downloaded it here in the office, and sure enough - it forks a new process for every page load. This is the browser architecture that I've been waiting years for, one where a script on one page won't kill performance in another window.

So, I went home and tried it on my single core Athlon at home. Ouch! The performance is terrible. The browser keeps locking up, it stops responding to mouse clicks, keypresses, anything and everything. It acts like alpha quality software, not the "beta" it is supposed to be.

I've got a 2 year old system (Athlon64 3800+), the only difference between it and new ones is that it is single core. It's still fast enough to play new games on, but it can't handle Google Chrome.

I can only assume that Google Chrome has a tendency to starve some of their child processes on single core machines.

In the meantime, I'll stick with Firefox 3. It leaves Google Chrome in the dust.

Duck Typing Sucks.

I'm working with some code that's written in Python, and makes extensive use of duck typing. In duck typing the premise is that if it quacks like a duck, it is a duck.

Of course, if you've got code that doesn't tell you what it expects to receive, you can't hope to figure out what the type should be.

For example, let's say you've got 3 code blocks:

class A:
    def funkyDuck():
        # random cool stuff

class B:
    def funkyDuck():
        # entirely different cool stuff

class C:
    def funkyDuck():
        # a third entirely cool thing

Now, imagine you're looking at code that goes:

some_random_object.funkyDuck()

Which one gets called? By the way, they're all in different files, so the only way to find them is with "grep". Added bonus, the undocumented hash!

    def addApplications(self, appDict):
        """ Add some application modules to the defaults.
            All binaries and libraries in any of the source dirs will be soft linked
            to a directory with the name of the product.
            @type  appDict: dict of string -> (list, string)
            @param appDict: The source dirs and OS user name for each product
        """

Guess I'm supposed to guess what appDict actually looks like.

Hrm. Perhaps my problem isn't with duck typing itself, but it's use here.

Hint: When your test framework is just as complicated as the program under test, you're doing something very, very wrong.