SloppyThoughts

CommercialTube

Much has been made, recently, about Comedy Central's decision to require YouTube to pull copies of the Daily Show, Cobert Report, and South Park. The move has been almost uniformly condemned as being foolish, and a good way for Comedy Central to alienate its fans, resulting in fewer live viewers.

But in a simplistic sense, it's the right move. Any service that uses ad impressions as their primary source of revenue must attempt to curtail any situation that reduces the number of eyes seeing those ads.

Or replace it.

Comedy Central and other services need to make YouTube part of their revenue stream ... either with the same business model or a new one. Not just as hooks to get live viewers, or free research with which to determine which episodes should be in "best of" DVD releases (the only kind of DVD release likely to be viable with a current events show), but as ad impression-generators as well. To make this desirable and successful, YouTube will need to facilitate the process ... soliciting contributions from companies like Comedy Central that have advertising incorporated in the video, preventing unapproved copies of the video, and providing verifiable metrics on viewers.

Unfortunately, it may be too late now. If this had been done instead of pulling all the Comedy Central content, fans might have embraced the convenience, even if they had to suffer through the same ads (although I'd hope Comedy Central would recognize the need for shorter ads in that context) ... but now the same act would be seen less as an attempt on Comedy Central's part to provide value to viewers and customers, and more a blatantly mercenary act done with total disregard for the viewers. Comedy Central, without extreme creativity, can only be the villain, now. YouTube can be the hero.

Today's Blinders

Tom Smith has decided to trot out both Socialist fallacies and an ignorance of the lifecycle of technological innovation, and since people are actually paying attention thanks to an Instapundit link, I felt I must respond.

There's rarely much hope in talking about creating the value in money, or the imaginary zero-sum game, or the fact that huge dreams provide huge motivation to those who can accomplish great things and provide so much value to the world (which then *gasp* pays for it), or any of the usual tripe-prevention, and I won't comment at length on the contemptible act of suggesting that Charles Simonyi and his like-minded dreamers fantasize about sexual promiscuity to rival some of Heinlein's characters. Those aren't within the scope of this blog anyway.

But I will comment on Smith's apparent ignorance of the life-cycle of technological innovation.

Most revolutionary innovation goes through a very predictable sequence. First is the basic research and commercial idea ... proof of feasability. Many people think it is appropriate for the government to finance this effort, although I do not. The first commercial idea is almost always bare-boned and ridiculously expensive. Its commercial success relies on rich people or corporations (or governments) buying the item.

Next is a period of refinement ... standardization of production methods, improved efficiency, cheaper materials. Entire industries can be created during this process, and the end result is typically a cheaper, but still bare, product available to the masses. Please note, however, that if the original customer of the item is a government, it is frequently unnecessary to go through this process, and the item remains in the hands of the government or major corporations.

The next step is to come up with desirable frills. Again, they start off expensive and are marketed to those who can afford it.

And the last phase is, again, making the new, full-featured product cheap enough for the masses. This is the point at which consequent innvoation just explodes.

ENIAC on one end, Napster's peer-to-peer software architecture on the other. Gramaphone on one end, pink leather-sheathed Ipods on the other. Otto's and Daimler's gas engines on one end, rural power generation and food transport adequate enough to support large cities on the other. Cameras. Cars. Computers. Boats. Airplanes. Telecom. Books. Electricity. Plumbing supplies. Fertilizer and farming equipment. Anything made of steel. Anything made of plastic.

And the future of space flight.

And all because a few "selfish" rich people found it worthwhile to buy something during the expensive steps. So really ... cheer loudly for every expensive purchase you consider frivolous, or give silent thanks to the value they provided to get rich and their invaluable contribution to the things you and your descendants will enjoy.

Or find a cave and some lightning-struck fire, and condemn to your heart's content.

Update: Hello folks from Instapundit. Welcome to my formerly quiet hole in the wall. Just to clarify Glenn's characterization of my position ... it's not that I thought that he was approving Smith's analysis. It's that I thought he was either approving Smith's analysis OR providing both soapbox and audience to his adversaries. I could not understand either act. Regrettable confusion ensued.

Transactions

I had to track down a series of problems this week, all related to transactions and database interaction. Many of the conclusions I had to make are mere guesses, but they seem plausible, so I thought I'd mention them here (as, once again, I found little on the 'net to support my efforts.)

• Prior to .Net 2.0, the easiest way to manage distributed transactions was to implement certain functionality from EnterpriseServices and dump your assembly into COM+ component services. However, it would appear that if a class in COM+ calls a method on a class that does not implement EnterpriseServices, the called method is not (may not be?) included in the distributed transaction.
• If you have an operation that makes one connection to a SQL database, it uses a lightweight transaction. If you have an operation that makes use of two or more connections to a SQL database, the original lightweight transaction is promoted to a distributed transaction when the second connection is opened. Referring to item 1, if this second set of calls is not in COM+, the second DTC transaction will not necessarily join the first. Therefore, any locks and such made by any connection made by any method on any class in COM+ have the possibility of blocking any locks and such made by the connections in the non-COM+ class.
• If you make database calls from a class that someone has marked as not supporting transactions, it will go through the same process of promoting lightweight to distributed transactions in that class regardless. They will not, however, be incorporated into existing DTC transactions, and, once again, you have the possibility of lock contention.
• The new .Net 2.0 TransactionScope is, shall we say, your friend. If you use it in the context of a transactional .Net COM+ component, the TransactionScope object will utilize the existing DTC transaction. If you're wanting to move away from COM+, this is a good start.
• If you have a procedure that writes to temp tables, these operations are transactional. If you're using lightweight transactions, and the number of records is substantial, this can cause unnecessary load on the database. If you're using distributed transactions, you may have real problems. It would appear (although I'm guessing, as I've found no documentation) that information about the operations have to be sent to the DTM or DTC. This is not fast. A procedure that runs in, say, half a second within query analyzer may take a minute or more when run in the context of a distributed transaction. Remember to be aware of the implicit promotion to distributed transactions. And rewrite your procedures to get rid of that many temp table writes!

Oh, and don't forget ... if your connection is timing out, and you're considering increasing the connection timeout (easily done on the connection string), don't forget that there's a timeout on the Command object as well, not to mention global- and component-specific timeouts (timesout?) for the distributed transactions.

Share and enjoy.

Observation du Jour

The management of a company is rarely composed of the people who can do the tasks of the business.

Tasks can be so ridiculously complex as to make QED look like a kid's game, or they can be trivially simple.

Two Feynman clones thrashing through the equivalent of validating a Unified Field Theory will look nearly identical to a couple of Amazonian tribesmen dealing with the complexities of, for example, "hello world", when observed from the perspective of upper management. Remember this when it looks like management considers your efforts to be "no big deal".

SQL Interview Questions

Tim Chapman has an article on TechRepublic describing questions you might ask a SQL Server database developer applicant. I think a more accurate title for the article would be "How to Make Sure You Hire a Mediocre SQL Server Database Developer." The questions Mr. Chapman suggests can be answered by anyone who has remained awake for a few of their relational database theory classes or have skimmed one book. And if you want to ensure that your prospects have, at least, heard of relational databases, by all means use these questions.

On the other hand ... well, let me give you a few examples of my interview questions:

• What is the difference between a table variable and a temp table, their intrinsic and situational drawbacks, and some of their uses? What happens if you do a "select into" a temp table without defining the table ahead of time?
• What constraints are there on calling stored procedures from user defined functions?
• If you're doing a left outer join against a large table with 0:1 cardinality (hey, what is cardinality?), how might you rewrite the operation to be more efficient?
• With regard to indices, what's one of the benefits of using integer primary keys as opposed to guids?
• What are some of the techniques for managing record change audit trails and their drawbacks/benefits?
• Suppose you're considering changing the parameter list on a stored procedure. How might you determine if any other stored procedures call the one you're wanting to change?
• What should you worry about if you're using more than one SQL connection in the same operation? Does the operating system matter?
• What's a two-phase commit? When is it used? What does it mean to have a transaction "in doubt"?
• You have a procedure that you've been told is running too long. What steps would you go through to track down and resolve the issue?

And these are just the questions for SQL 2k. The ones for 2k5 get even more fun.

Causal Awareness

One of the companies I worked with in the past once had fits because a significant portion of the internal user base failed to change their passwords from the system default. They implemented a nicely complex process by which you register, validate, and are then forced to change your password. Which is all very well and good ... you've reduced the risk caused by that one security hole.

But to me, this was a sign that the company needed to take some serious effort raising the awareness of its internal users about security risks. Seriously, if your users aren't aware that a default password is a bad idea, they certainly aren't going to be cognizant of the risks of, for instance, "social engineering".

Obvious Item of the Day

An article at Geek News Central comments on the possible Bell re-merger. The article notes the ironic fact that breaking up AT&T and the Bells actually resulted in a stronger AT&T. I'm not sure why this is surprising, unless you fall for the "anyone who has a majority of the market is a monopoly" definition.

In a free market, monopolies only exist when they are established and supported legally ... in other words, they need government help to be viable. They need this help, typically, because they are not competitive. If you force them to compete, they grow stronger (as we all learned in elementary school lessons in evolution.)

If you supported breaking up the Bells in '82 ... you didn't have to break them up. All you had to do was remove the protection. You forced them to compete. Why complain now about the inevitable consequences?

You want to be worried about something? The author specifically mentions his time selling MCI. MCI used to be a service to allow trucks to communicate. Some guy had the bright, but extremely risky idea of converting that to a long-distance service. In order to finance such a risky venture, one extremely creative financier came up with a new financial tool. His reward? Rudy Guiliani manipulated him into prison. Guiliani's reward was to be voted mayor of New York City. What do you think that did for competition?

Give me all the "monopolies" you want. Protect me from overzealous politicians with broadly-reaching laws and a culture that thinks that Capitalism is intrinsically evil.

As for AT&T ... their re-merger will either result in better products or a weaker company, provided they are not granted government protection in the market. Either way, I win, so what's the big deal?

Hotspot ... in Your Wallet

I discovered a charge on one of my credit cards that I rarely use (and used last just for the purposes of moving). It was from T-Mobile Hotspot, the wireless service that Starbucks has chosen to use to provide Wi-Fi in their establishments. I purchased the account in order to have Internet access during the 1-week period in which I was actually finalizing my move.

They have a daily $9.99 charge, and a monthly $29.99 charge. I debated whether I would need the service more than 3 days and, concluding it was likely, purchased the service for a month.

So imagine my surprise when I see a charge for the service on my bill, go to the HotSpot site, and discover that the plan I've signed up for requires a 12-month commitment! News to me, let me tell you. Firstly, I've used the HotSpot service before, and didn't commit to any 12 months of use. And secondly, I'm a bit of a stickler for looking for little hidden ... shall we say, "unexpected charges" like that, so the likelyhood that I missed it IF the Starbucks interface wasn't specifically intent on concealing that information is highly unlikely (assuming it presented it at all, at the time).

Furthermore, as the "customer service" person told me ... once I specifically asked ... at the end of the 12 months you roll over to a month-to-month service which also continues being billed until you cancel it. Which, it would appear, you can only do by phone. So I could either cancel the service ... which I haven't used in 7 months and, I can tell you, have no intention of ever using again ... now, paying for the remainder of the year, or I have to make sure I cancel it right at the end of the year.

Look, let me honestly ask since I didn't actually go to business school ... is there a class these guys specifically take to teach them how to make their quarterly numbers at the expense of losing customers? Perhaps entitled, "why it's not really fraud"? Inquiring minds want to know.

Longevity and Obsolescence

Computers, particularly those assigned to software developers, have a very limited lifetime.

If your domain administrator gives computers generic names, the implication is that the hardware has more potential for longevity in the company than the employee using the thing.

Little things like personlizing the name of your employees' machines can make a significant difference in the psychological state of your employees.

Implied Odds

One of the things I've learned from playing poker is that players who display sophistication, subtlety, and nuance are frequently viewed as inept by players who lack these qualities.

For instance, if I'm chasing the nut flush, and my only adversary in the hand is someone who rarely protects their hand prior to the river, and never believes when their opponent makes a hand and will always call a big bet after the river, it may be worth my while to call a $500 bet with the expectation that I'll be able to acquire 5 times that amount if I do hit. In poker parlance, the odds you calculate with the expectation that you will make that amount in the end are the "implied odds", and it appears to be a concept well beyond your typical, casual player. If you can put up with being called a "donkey", or worse, it's frequently well worth the risk and effort.

Comparable situations can pop up in business. For instance, suppose you construct a demo to facilitate sales that describes the process you utilize to provide a set of services. The typical, unsophisticated reaction is to make every effort to keep your competitors from getting their hands on that demo.

But let's consider an alternative ... what are your competitors going to do if they get it?

Well, they're going to analyze your business process and poke holes in it when they're competing on a sale. Which you should already have done yourselves, so you can easily innoculate your prospects and make your competitors look foolish in their efforts. Furthermore, your prospects get to wonder why your competitors aren't open about their processes, and what exactly they're hiding, and your competitors now have to fight back against the perception of being untrustworthy. You also encourage your competitors to chase you, so while you're enhancing your own value, they're trying to match you (as I've mentioned before, exceptional companies pursue values; struggling companies pursue competitors.)

So which would you rather be ... obvious, or go for subtlety and the implied odds?