Thursday, October 25, 2007

How to lose a million and be smarter for it

What I Learned Losing a Million Dollars should have more recognition (not to mention distribution) because what it has to say is excellent. It tells the story of Jim Paul, a trader "from hunger" who rode some combination of luck, timing and hubris all the way to the Executive Board of the Chicago Mercantile Exchange. Then he gets a wild hare that bean oil futures are going to skyrocket, and when they do, he doesn't get out. He stays convinced that they're going to the moon... and they don't. $1,200,000 later, he loses his seat on the Exchange and discovers that he had never been a trader after all. Really just lucky.

But why did he stay in? He proceeds to take the psychology of market loss on a trip around that mountain. After a market loss, most people study a different way to find profit in the market, in order to make the money back. And Paul did that for a while, but discovered that all the great traders contradicted themselves on what worked. Where they agreed was that one should not lose money. "There are as many ways to make money in the markets," says Paul, "as there are participants. But only two ways to lose it."

Losses, Paul explains, occur either due to a failure of analysis or failure to execute on the analysis. Most analytical methods allow for some loss, which is expected, but catastrophic loss is typically due to a failure of execution. So, how do you not fail to execute?

First, you must understand your motive for participating in the market. Is it a "profit motive" or a "prophet motive"? Do you want to be right or be rich? Because if you want to be right, a continuous process like business markets is probably not for you. You should play poker. If you want to be rich, you should be careful not to confuse the two, and proceed to make some further distinctions: what is your stop-loss point, why are you entering, and what is your goal, in that order.

Applying this metric allows you to take the beneficial properties of games, that of discrete bets or gambles, and apply them to markets. You're "chunking" your risk exposure into discrete blocks that you are aware of before you enter the market. Then your market play becomes a simple if-then series.

I mention all this because I'm watching my father struggle after 8 months floundering in the job market, and his words echo that of Paul losing his bean-oil futures. "It'll turn around! I'll certainly have a job by April." Well, what if you don't? What's your stop-loss point? When are you going to exit this obviously failing market? Hiring, like any market, is a continuous process, and to forever expose yourself to the risk of your share in it plummeting is a fool's game.

The lesson applies equally well to businesses. We've changed our profit strategy several times here at Treemo because we're not so foolish as to think being "right" will create a sustainable company. Mobile media sharing has a lot of possibility, and sticking to one of them in the face of obvious failure is a great way to burn a lot of investor money. We're happy with the stance we're taking right now, and it's getting a great response in the market. It took plenty of experimentation to get there.

But more than that, we've got controls. The business plans have direction changes in them for when business dries up in any area. There's plenty of stop-loss, so I sleep well at night knowing that long before the bank account gets thin, we've got a plan. And so should you. What are the markets you invest in?

Most of us have a job market in which our investment is our time and training. We also have networking markets that we play, knowledge markets, even habits. What are the areas that you've internalized external markets that fail you? Do you, like my father, see a dry job market as a reflection of your self-worth? Is that going to cause you to hold to a failing strategy just to prove yourself right? Or will you have the prescience to exit because you'd rather be rich?

Saturday, October 20, 2007

How to get character encoding right in Smarty

Smarty is a great tool, but like its underlying PHP, has no native understanding of internationalization. One aspect of it that's easy to get wrong is character output encoding. Fortunately it's also fairly easy to get right.

HTTP useragents send a header with their requests named "Accept-Charset". This header has a really stupid format, the parsing of which I'll address another time. For now, let's start from the point where you know what encoding the client prefers. Let's say it's something really weird like BIG-5. All your Chinese Smarty templates have text stored in UTF-8 because you're a good programmer. How do you get those lovely UTF-8 templates mangled into something this silly UA likes?

First, if you're even reading this post, you're probably aware of PHP's mbstring library. This library offers a lovely function called mb_convert_encoding. The basic idea is to attach an output filter to Smarty that runs the template output through mb_convert_encoding. Here's how this looks:

* This sets an internal property in the PHP instance. Of course, this should be set to whatever the UA wants, within reason.

mb_http_output( "BIG-5" );

function convertEncoding( $templateOutput, &$smarty )
return mb_convert_encoding( $templateOutput, mb_http_output() );

$smarty->register_outputfilter( "convertEncoding");

* You must send headers so the browser knows that you gave it what it wanted
header( "Content-Type: text/html; charset=".mb_http_output());

Now, when you call display() or fetch() on that Smarty instance, all its output will be converted to the current value of mb_http_output() - even if the file was already cached!

This approach guarantees a few nice things:
  • It does not depend on output buffering
  • It is insulated from changes in php.ini
  • Only templates have their encoding converted
  • The encoding can be converted on a per-request basis
So go get this right, and stop sending everybody ISO-8859-1.

Sunday, October 7, 2007

On ensuring conceptual integrity in systems design

Fred Brooks outlines 3 essential points about systems design:

  • Conceptual integrity is the most important consideration
  • Deciding precisely what to build is the hardest part

  • The focus of any organizational structure must be on solving the critical need for communication

Some of these depend on each other, which can be represented graphically:

Of course, you can't just do these things in order. Over the course of everyone actually building the thing, decisions about what it will do must be revisited.

So, to make a great system, first one must decide what it will do, then ensure that its concepts remain coherent, then communicate constantly and easily with everyone building it. At Treemo, I sit right at the second step in that list, and am working on becoming better at the third, as it is increasingly required of me.

Anyway, these concepts are software engineering 101. Every tool, process, idea, program, or proposal that crosses my desk is going to have this diagram applied to it. "Does this thing solve a communication problem and/or reinforce our software's conceptual integrity?" It seems simple, but most things don't pass. Sometimes I feel like people turn their brains off when evaluating things like this. Software is hard, yes, but process of making it is over 50 years old, and the thousands of software projects that have lived and died in that time can tell us a LOT about how to make solving that hard problem easier. We have such ignorance of our history in this industry. I've only been a professional developer for a year now, and I've reinvented hundreds of wheels both in my code and in my organization. It's exhausting sometimes.

Also worth addressing are the blocks on the bottom of the first diagram: transparent trust, shared vision, and sharp tools.

First, you're not going anywhere in any company if you can't trust those around you. The need in software for fluent, open communication cannot be met without grab-my-hand-over-a-cliff trust. Joel is right about this, even though he doesn't come out and say it. Gifting your developers with offices, decision-making authority, and free lunches is a wonderful way to create a safe environment where they feel free to create and speak.

Second, everyone making software must grasp their role in both the company and the development process. They must share that vision for their role and be enthusiastic about it, because if they're not, why are they working there? Being on-message is just as important for testers as it is salesmen.

Finally, sharp tools must be available to everyone who needs them. Michelangelo was known to work so quickly and so hard that he would work all night with a candle on his head, chiseling furiously until the marble dust choked the air of his workshop. How many chisels do you think he owned? When you look at the David, do you wonder at how much he spent on having them sharpened? This also ties in with the trust issue: put a fast computer in that office.

Now, to build a company wise enough that I don't have to spend Sundays thinking about this stuff...