February 14, 2006
Your blog isn't worth as much as you think
I've noticed several prominent bloggers using the "How Much Is My Blog Worth" tool. This engine is a good example of a common economic fallacy: accepting appraisals uncritically.
Valuation of many things: homes, companies, even things as simple as jewelry, is difficult. It can be summarized in one simple axiom, though: something is worth exactly what someone else is willing to pay. It's isn't worth any more.
If you can't find a buyer for something at its appraised value then that appraised value is wrong.
So -- to pick on a random blog -- RandomURL is listed as being worth $20,888. Is it really worth 21 grand?
Probably not. Someone would have to be willing to part with a new car's worth of cash for this valuation to be accurate.
The research behind the blog valuation is based on the $25 million purchase of Weblogs, Inc., and appears to extrapolate down based on links within blogs.
The best appraisals are based on comparable sales. In real estate, for example, if you can find a house similar to yours its recent sale price is a good estimate of your home. Restated generally, two parties just exchanged something very similar to yours. You can probably find a buyer for a similar price. (The new site Zillow will value your home using this method.)
In this case, the study's author is comparing a $25 million sale of a corporation with a (usually) one-man Web site whose actual worth is on the order of, at best, thousands of dollars. The values are widely divergent and the two entities are different. It means the study is fatally flawed.
A better appraisal would be based on someone's one-man blog being bought for cash. Does anyone know of such a transaction? If you do, post a comment or email me.
Finally, it's very difficult to transfer the value of a blog because a blog's worth is dependent on the author's ability to continue to attract an audience. If the site is sold, why would the author continue to write? They no longer own the site. If a blog author wanted to get cash from their site they would be best off advertising.
February 13, 2006
"Republicans Buy Shoes Too"
There's an apocryphal story that goes like so:
Michael Jordan had just been drafted into the NBA; everyone knew he would be a big player. He had signed a shoe endorsement contract with Nike.
Strom Thurmond, the deeply reactionary Senator from South Carolina was up for reelection. Jordan grew up and went to school in neighboring North Carolina.
A reporter asked Jordan why he didn't use his fame and speak out for Thurmond's opponent, whose politics were more in line with Jordan's. Mike replied:
"Republicans buy shoes too."
He didn't want to lose fans because of his taking controversial issues public.
The moral of the story is that you alienate customers by expressing partisan sentiment versus being demure.
February 11, 2006
XML: When to use it and when not to use it
XML is overused.
I'm not sure why. I suspect it is because that XML is standardized and because of the prevalent attitude that all things with a W3C standard are good.
However, there are many times XML is selected to represent data or (worse) behavior where that selection is a poor decision. The best examples of this mistake are programming languages that are XML: Ant, NAnt, XSLT, and VoiceXML, for a few.
XML is verbose and puts awkward constraints on syntax. The strained syntax in VoiceXML is an illustration. Writing VoiceXML -- something I've spent much time doing -- is tedious and error prone. If you want a simple if/then/else construct, you need to type <if> … <elseif /> ... <else /> ... </if>. The result looks more like hieroglyphics than readable code.
The VoiceXML creators could have delivered all the same features by just making it an extension of an existing language. Developers wouldn’t have to learn a new syntax and wouldn’t give themselves Carpal Tunnel syndrome from typing all those <, >, and / characters.
Another particularly odious example is passing complex data structures as method parameters. I've now run into several organizations that have as a corporate standard architecture that you create an XML document to pass to another logical layer.
I'm not talking about using Web Services or passing data across process boundaries -- I'm talking about passing, say, three strings in an XML document -–
doSomething( Document document ) -- rather than declaring a method
doSomething( string foo, string bar, string baz ). Onyx's CRM platform uses this antipattern as their integration framework.
This is such a bad idea I don't know where to start. For one, when you encode things in XML, you lose type. You need to write logic that encodes your parameters in XML and then more to unencode the parameters from within the target method. The extra statements obscure your code.
All this for no benefit that I can percieve.
XML is chosen for two main reasons, one good and one dubious.
The first reason -- and a good one -- is that there are numerous stable XML parsers. Free, readily available tool support is a good reason to select a technology, but it doesn't override all other concerns.
The dubious reason people select XML is because it is standard and allegedly non-proprietary. XML is so weakly typed and amorphous that its ultimate definition is proprietary. Microsoft Visio saves diagrams to XML, but that specific format is proprietary. It is solely owned and controlled by Microsoft.
To sum things up, here are some general rules on when and when not to use XML:
- If you're representing logical statements -- a programming language -- never use XML.
- If you need only simple, non-hierarchical data representation, don't use XML.
- If you need complex data represented externally to your program (to a human or another unrelated system), consider XML. If you do select XML, unit test the logic that persists and retrieves it well.
- If you need complex data represented only internally to your system, bias your decision away from XML. In Java and .NET, for example, you can binary serialize your object graph. Performance is better and you don’t have to write as much code.
- Finally, if you're looking at some other application I haven't mentioned above, carefully consider the pros and cons of using XML. In general, the positives of XML are too strongly weighted and the negatives overlooked.