Recent blog entries for apenwarr

2008-07-22: iPhone 3G

<!-- start of entry 200807/22 --> iPhone 3G

"If you've ever wondered what Apple will be like after Steve leaves and they've got visionaries like Phil Schiller and Tim Cook running the place, well, now you've seen the trailer. The movie will be worse."

-- Dan Lyons (aka Fake Steve Jobs) on the iPhone 3G release <!-- end of entry 200807/22 -->

Syndicated 2008-07-22 22:52:15 from apenwarr - Business is Programming

2008-07-17: It lives

<!-- start of entry 200807/17 --> It lives

The company that I co-founded and eventually left lives on as Lotus Foundations.

There's even a guy blogging about it. (He includes some screenshots of the new webconfig and boot screens. The webconfig update looks quite classy.⁽¹⁾

It was also featured in the keynote at Lotusphere 2008.

And speaking of things that aren't dead, I discovered all these links using the beta of Pressflip, formerly Persai, a surprisingly non-sucky news engine from the guy who made uncov. I'm not usually impressed by Web 2.0 startups, to say the least, but this one is pretty cool. Check it out.

Footnote

⁽¹⁾ The boot screen is less classy; when they changed the "Nitix - Autonomic Linux" title in syslinux to say "Lotus Foundations", they centered it incorrectly, probably because they counted the colour code bytes as visible characters. Probably nobody else would ever notice this, except that I've done it myself in the past. <!-- end of entry 200807/17 -->

Syndicated 2008-07-18 02:51:39 (Updated 2008-07-18 05:05:32) from apenwarr - Business is Programming

2008-07-04: Risk vs. Calculated Risk

<!-- start of entry 200807/04 --> Risk vs. Calculated Risk

It's accepted knowledge that potential returns in business are greater if you're willing to take on more risk. That is, a "safe" investment with guaranteed payoff will generally offer less than an "unsafe" investment that might fail. And so, if you have lots of money, as the wisdom goes, you might want to invest it in a wide variety of risky investments in order to collect some of that potential gain. The idea is that even if some of the risky investments fail, the increased profits from the non-failing ones should more than pay for the loss.

Okay, so far so good, but the problem with risk is that it's random. And worse, there are a lot more worthless risky investments than valuable ones; such is the state of humanity. (In contrast, "safe" investments, by definition, don't really have that problem.)

Enter the concept of a "calculated risk." The idea here is that if you're careful, you'll be able to see which risky investments are better, and thus collect on the returns instead of losing all your money.

But there's a problem with that theory. The problem is that if everyone could just figure out what's a "good risk" vs. a "bad risk," then everyone would want to invest in the same things. Thanks to supply and demand, this basically sucks the profit out of such obvious investments. Various problems with fancy hedge funds and the recent subprime crisis can all be traced to this problem: everyone agreed that a particular risk was "good" at the same time, and over-invested in it until the profit was gone.

But wait! If supply and demand can suck the life out of risky invements, what makes risk such a great thing, again?

My entrepreneurship professor in university used to say that a better term for calculated risk would be "risky calculation," because that puts more emphasis on calculation than on risk. And the more I learn about business, the more I realize how absolutely right that is. Profits don't come from risk. Of course they don't! Who wants to buy pure risk, except compulsive gamblers? Profits actually stem from the quality of the investment, and you can buy into an investment at a good price only when other people don't. Perceived risk is just one possible reason that people might avoid a particular high-quality investment.

I don't have huge boatloads of money, so I don't usually think about investing from the point of view of investing money. I think more about where to invest my time, because my time is the most valuable thing I have. Right now, the cool thing for a programmer like me to do is to form a web startup. But I'm not doing that, because the space is risky and overinvested. It's completely wrong on both axes. If you want to be successful in the market right now, do something safe and underserved. <!-- end of entry 200807/04 -->

Syndicated 2008-07-02 19:54:11 from apenwarr - Business is Programming

2008-07-02: Toronto Fringe Festival Suggestions

<!-- start of entry 200807/02 --> Toronto Fringe Festival Suggestions

Congratulations, Torontonians, your Fringe Festival starts today and runs until July 13th. Since a lot of shows tour from East to West and Montreal is the first one of the season, my friend Elaine asked me to recommend some good shows based on what I saw in Montreal. So my good deed for today will be to offer you some assorted preview reviews:

• Blastback Babyzap. Go see it. It's by Uncalled For. QED.
  
• Teaching the Fringe, by Keir Cutler. Except that Dr. Cutler won't be able to make it to your fringe, so Barry Smith, of Barry Smith's Baby Book (not to be seen in Toronto), will be doing the show on his behalf. That's a bit strange, because both Teaching the Fringe and Baby Book are autobiographical, and so now Barry is doing someone else's autobiography. Oh well, both of them were good. You might as well give it a shot.
  
• American Squatter, also by Barry Smith. Apparently it was popular. I didn't see it, but Smith himself is pretty funny. Who knows?
  
• 'Beth. As advertised.
  
• Transcendental Masturbation. Not as advertised.
  
• Wonderbar! and Balls! Both titles are exclamatory, but both shows I missed.
  
• The Diaries of Adam and Eve. Luckily for you, it's cancelled.
  
• The Tricky Part. Didn't see it, heard it was awesome.
  
• Die Roten Punkte. Go see this. Really.
  
• Telegrams from the New Canadian Cinema. Didn't see it. Heard nothing about it.
  
• Time to Put my Socks On. Be sure you know what you're getting into.
  
• Crude Love. Reputedly good. I didn't see this one either. Gee, I'm starting to sense a pattern here.
  
• Greed. Well done. Time-twisted plot exposition. Cute girls.
  Update 2008/07/02: Hmm, I've been told there was only one girl. Anyway, she had many cute outfits.
  
• Jem Rolls. Dude, it's Jem Rolls. Of course you have to go see him. If you don't know why, then you have to go see him even more.
  
• Mating Rituals of the Urban Cougar. Pretty good, especially the songs. Unless I got it mixed up with something else, that is. Actually, I'm pretty sure I did. Well, it was pretty good anyway, I think.
  
• The Spy. This came to Montreal for a one-night show. The guy was super nervous and unfortunately it showed. But the show was otherwise excellent, and if he can get into his groove, it'll be awesome. Maybe wait for a later showing just in case.
  
• Totem Figures, by the increasingly infamous TJ Dawe. The guy talks at top speed for 90 minutes and doesn't forget any lines. Worth seeing just for that, although he seems a little oversold to me. Reputedly the only guy to ever make a full-time career out of doing fringe shows.

And two troupes with three shows that you won't be seeing because they're not coming to Toronto but they're so awesome that I have to mention them anyway:

• Identity Crisis by Influxdance. More serious and scaled down than previous years, but still excellent. Sadly, they seem to be done for the summer. Too bad.
  
• The Cody Rivers Show: Stick to Glue, and Boom (by one guy from the Cody Rivers Show). Neither of the members is named Cody Rivers, but they're both awesome. Looks like they'll be in Edmonton, if you're lucky enough to live there, or Minnesota, if you're not.

And by the way, if you're going to the Toronto fringe, make sure you mention to them how lame the Fringe Donation Buckets system is, where you basically have salespeople nagging you while you line up for every single show. Please, please, if your fringe festival is going to collapse without these donations, then just charge a service fee per ticket like they do in Montreal. Seriously, guys. It's either optional or it's not. Stop harassing me already. You want people to go to more shows, but the lineup harassment gets less fun every time.

But all that said... you Torontonians have a great selection of shows waiting for you, including a huge number that didn't make it to Montreal. Have fun fringing!

Previously.

Update (2008/07/02): jnc has some alternative opinions. <!-- end of entry 200807/02 -->

Syndicated 2008-07-01 04:38:52 (Updated 2008-07-02 20:04:31) from apenwarr - Business is Programming

2008-06-30: A serious case of JustOneMoreBug

<!-- start of entry 200806/30 --> A serious case of JustOneMoreBug

I just read Waking Up from the Economy of Dreams, a pleasant essay about how Webmind, Inc. went bankrupt in 2001 while trying to invent artificial intelligence.

The essay is an interesting read, mainly because the author seems to have come out of the experience so... innocently. We were 3/4 of the way to a real, working AI, he insists near the end of the story. It was just bad luck that we ran out of money right as the .com bubble burst...

You might almost be able to believe him, except he also told the rest of the story. The original development was supposed to take a few months. To build the first sentient AI! Unsurprisingly (to me), it took longer than expected. They actually ran out of money multiple times in the process, but managed to land financing at the last minute each time. (Incidentally, that sounds to me like a long string of good luck that finally ended, not any bad luck at all.)

But okay, lots of startups almost run out of money, and just about everyone underestimates the amount of work involved in their project. So what?

Well, the problem is that these guys felt sure, at each failure along the way, that they were just one step away from having it finally work. And when they finished that step and it still didn't work? Well, now we're just one step away. We're almost there. We can feel it!

At NITI, we called this the JustOneMoreBug syndrome, spelled using WikiCaps because it was a page in our wiki. It seems now that we must have been the ones to invent that term, since I can't seem to find it in Google anywhere. So with that in mind, I guess I'd better tell you what it is:

First of all, the fact that this was featured in our internal wiki probably tells you something about our experience with it: ie. we had plenty.⁽¹⁾ JustOneMoreBug is exactly what it sounds like: the feeling that if you can just fix this one last bug, your software will work perfectly, customers will come flocking to you, and riches will inevitably ensue.

The frustrating thing about JustOneMoreBug is that every successful project does have a moment exactly like that: the transition from unreleasable to releasable, from unusable to usable, from unsellable to sellable. And so if you're an optimist, you, like us, would prefer to believe that this bug is your one last bug. And maybe it is.

Unless it's not, which becomes clear one way or the other shortly after you fix it. Then what?

Then, if you're experiencing the JustOneMoreBug syndrome as opposed to the JustOneMoreBug major life-changing event, you realize that there's just... one more bug holding you back.

Fool me once, shame on you. Fool me twice, shame on me. You can get away with claiming JustOneMoreBug once or twice per project - but if you go past that, you have to stop and rethink. Why are there so many bugs that you don't even know about yet? Believe it or not, really good programmers will write programs that mostly work the first time, and the parts that don't work can fairly easily be uncovered and solved. If your program is fooling you about how stable it is, it's because your program isn't very good. You need to stop and find a new strategy: often, by doing some heavy testing and using the results to build a brand new multi-month development schedule. That's bad news, because the project was supposed to be done tomorrow. After all, there was just one bug left.

Webmind was on a multi-year marathon of JustOneMoreBug. I feel sorry for them, because advanced research has a strong tendency toward that; structured engineering principles just don't work for software research projects. But it seems like their investors didn't realize they were doing software research, and their researchers honestly didn't realize - repeatedly - that the JustOneMoreBug feeling is just a feeling, not a reality. And if the essay is any indication, they still don't realize it; they still think they were almost there.

At least they didn't come out cynical.

Footnote

⁽¹⁾ NITI had two kinds of JustOneMoreBug experience. First, with certain internal software projects (which is normal occasionally in any software company, although if we'd been smarter we would have caught them sooner). And second, with our business model: even if your product works, if it's not selling as well as it should, there's a strong tendency to believe that you just need to tweak one more thing about your business and it'll take off. But just like with software, you shouldn't fall for this trick more than once or twice. We fell for it repeatedly, and that was our multi-year marathon. (Eventually the winning fix wasn't a tweak. It was a complete re-analysis and redefinition of our target market, and a corresponding total change in the way we dealt with customers and resellers.) <!-- end of entry 200806/30 -->

Syndicated 2008-06-29 23:29:23 from apenwarr - Business is Programming

2008-06-28: Weird things about git, #2: no bug tracking system

<!-- start of entry 200806/28 --> Weird things about git, #2: no bug tracking system

The git developers don't track bugs. If you find a bug, you can write about it on the mailing list. You might get flamed. And then probably someone will ask you to fix it yourself and send in a patch.

This is unlike almost all other open source projects. Virtually every project out there has a basic bug tracking system attached, courtesy of SourceForge or Google Code or whatever. It's a key part of the development process, right?

Well, not exactly.

I'm also following the development mailing list for Mono. It has much less traffic than git, which is weird, because at least by lines of code (and probably number of users), Mono is a way bigger project. One of the reasons for the quiet is their bug tracking system. It's a conversation killer. Like this:

Someone reports a bug on the mailing list. "Please file it in the bug tracker." "I can't figure out how to create a bugzilla account." "Do it like this." "Okay, I created the account, but I can't figure out how to file a bug." "Do it like this." "Okay, I filed the bug. Now what?" "Now hopefully someone will fix it someday! Bye!"

So people aren't supposed to discuss bugs on the mailing list, which begs the question: what are they supposed to discuss on the mailing list? Nobody really knows. So the conversation dies. And not everybody sees every bug that comes in. Which is probably good, because there are thousands of bugs filed, and as with most open source projects (and commercial ones, for that matter), most of the bugs never get fixed, because volunteers just aren't actually very interested in fixing every last one of your problems. (This isn't to say the Mono developers don't fix tons of bugs. Mono is awesome. But it seems to be a cardinal rule of bug tracking that the bug database only grows, it never gets smaller.)

Let's be honest: bug tracking sucks the joy out of software development. git developers just work on whatever scratches their itch at that particular moment. If the same question comes up too often on the mailing list, they update the documentation. If people report a bug, they quiet those people by fixing the bug (or convincing those people to fix the bug). If they feel like implementing a new feature today, then they just do. And with multiple examples of this happening every single day, it's easy and fun to subscribe, get a feel for what's happening, and join in.

When you work to a bug tracking system, you're just doing what you're told. Some poor bug tracking janitor spends hours each day shoveling bugs around inside the system and assigning them to people and prioritizing which ones go into which release. Then the developers line up and take their bugs, and work on them in sequence so that the release can go out at the pre-ordained time.

git developers just make a code freeze branch sometimes and let it simmer for a while, then release it. Junio C Hamano is the equivalent of the bug shoveler for git, except he doesn't shovel bugs: he shovels fixes. I expect that's a much more gratifying job.

Update (2008/06/30): YCombinator News has some commentary on this article.<!-- end of entry 200806/28 -->

Syndicated 2008-06-28 07:26:46 (Updated 2008-06-30 15:08:05) from apenwarr - Business is Programming

2008-06-25: How to tell the gcc maintainers are all (still) lunatics

<!-- start of entry 200806/25 --> How to tell the gcc maintainers are all (still) lunatics

Just got bitten by this insanity today.

There's not being backwards compatible, and then there's... that. What was the point of upgrading, again? <!-- end of entry 200806/25 -->

Syndicated 2008-06-27 01:57:43 from apenwarr - Business is Programming

2008-06-24: Weird things about git, #1: premature optimization

<!-- start of entry 200806/24 --> Weird things about git, #1: premature optimization

I've been hanging out on the git mailing list for the last little while, and a few things have been striking me as weird. There are hundreds of people on that list, and lots of them are active contributors. Why? It's just a stupid version control system after all.

But there must be some reason. I've thought of a few. Here's one for today:

The git developers are completely obsessed with performance. Apparently nobody there has ever heard that "premature optimization is the root of all evil." (Incidentally, the ACM has a recent article explaining why that statement is a fallacy.)

It's enlightening just to watch the git developers optimize every possible part of their system: syscall overhead, memory allocation, path trees, file size, network turnarounds, etc. And even while they optimize the heck out of everything, they still complain about how inefficient it all still is. Which it is, of course, if you follow the discussions.

Also interesting is that large parts of git are written in sh and perl and it's still fast, because while they obsess about performance, they also know which parts actually matter to performance. It helps to be a Linux kernel developer sometimes, I guess.

There's no doubt that git's optimization is premature: it started out way faster than svn, and it gets even faster with each release. Is that really necessary? Of course not. Everyone was doing just fine with things like svn. But life is just so much better when programs go unnecessarily fast. It's a very strange sensation; pain you didn't realize you were having just goes away. I've been doing a lot of Windows development lately, and let me tell you, Windows developers have a whole lot of pain that they don't realize they have, because it's not overt. Windows development is mostly fine, really. But what kills it is all the little random delays, the crashes, the giant memory-leaky .Net-based IDEs that make you point-and-click fifty things sequentially once a week because you don't have a way to write a script to do it for you. Just give me a text editor and 'make' any day, thanks.

What was my point again? Oh right, unnecessary optimization. While I've been writing this article, I've been waiting for svn to finish committing 20000 tiny files to a fresh svn repository. It's still not done. (Watching a strace of this is hilarious. Among other things, it's creating an XML file for every single one.)

...

And for comparison, git just did the same thing in 23 seconds. (About half that time was spent running my shell script to create 20000 files.)

Who cares? How often do you create a repo with 20000 tiny files in it anyway? Almost never, of course. It's not an important optimization goal.

...

svn finally finished. See? That wasn't so bad. <!-- end of entry 200806/24 -->

Syndicated 2008-06-25 04:02:54 (Updated 2008-06-25 05:05:41) from apenwarr - Business is Programming

2008-06-05: I Am Of Literary Significance

<!-- start of entry 200806/05 --> I Am Of Literary Significance

Oh yes. Fear me.

Stupid internet.

(The rather dull ancient high school essay that started it all. But this is better. Or maybe this.) <!-- end of entry 200806/05 -->

Syndicated 2008-06-03 02:55:05 from apenwarr - Business is Programming

2008-06-03: So... what do *you* do?

<!-- start of entry 200806/03 --> So... what do *you* do?

I got married a couple of weeks ago. We and our guests planted some trees:

But wait, I'm getting ahead of myself. The story goes something like this:

Erin and I got engaged shortly after she went tree planting last year. (I had been too lazy to get up early.) We thought it would be fun to have a tree planting at our wedding, so we set about trying to find a wedding site that would let us plant trees. Alas, there were none. But one of Erin's friends referred her to a berry farm out in the wilderness somewhere, which we visited and decided it would make a fitting wedding location. Sadly, they already had plenty of trees. We proceeded to the local coffee shop (there's only one) to discuss our strategy. I asked someone there, "So, let's say you happened to have a bunch of trees that needed planting. What would you do?" She looked at me seriously, thought about it for a second, and said, "How many?"

A couple days later, she set up a meeting for us with a local lady, Barbara, who happened to be planning to reforest some of her family's historical farmland with trees that originally grew in the area. (In Southern Ontario, many of the original forests were clear cut and converted to farmland, so a lot of the original species are getting pretty rare.)

We agreed that her land would be a great place for our tree planting, and she said she'd name it "Erin's Dell." She offered to pay for the trees. I said no, no, that's okay, we couldn't ask you to do that. Instead she formed a charitable foundation, got donations, and had the Ontario government match them so that Erin and I ended up paying nothing. She also picked the trees, hired a landscaper, got a local lady to bake fresh bread, and had everything ready for us the day we arrived.

Oh, also, it turns out that before she retired she specialized in public relations and marketing, so she could hardly resist issuing a press release. That's probably why the London Free Press showed up at our wedding (where our guests, by the way, were doing almost all the actual digging/planting work) and took the photo featured above. A couple of smaller local papers picked up the story as well.

So what's the point of this story?

Well, when you meet people, one of the first questions they always ask is, "What do you do?" Erin finds this question annoying, because it isn't the right question.⁽¹⁾

Ask yourself instead: if it weren't for her, how much of the above would have happened?

Footnote

⁽¹⁾ It's not actually the right question for me either. When I answer "I'm a Computer Engineer!" most people's eyes instantly glaze over and the conversation ends. That's not supposed to be the purpose of small talk, so I usually dodge the question too nowadays :)

Epilogue

And then our honeymoon in Salt Spring Island, BC, was almost entirely organized by Juli, my bus driver from high school. I am not making this up. <!-- end of entry 200806/03 -->

Syndicated 2008-06-02 18:34:59 from apenwarr - Business is Programming