if (isNerd) return true

Moved

2010-09-27T05:43:00.000+08:00

Quick shoutout: I've moved my learning blog to Tumblr, at metacog.tumblr.com. This blog is frozen for posterity.

Google Kills Wave

2010-08-05T09:44:00.002+08:00

Half a year ago I wrote:

Is all lost? The answer to this isn't clear. It could be that Google Wave would, against all logic, live up to its hype. It could also be possible that Wave flops, completely, and is discarded as Rasmussen and co. leave the project to work on something (hopefully) more useful. Or it could even be possible that Wave turns out to be a sleeper hit - that it fails in its intended purpose as a communication platform and is then adapted for uses its creators never thought imaginable.

I had no idea how right I was.

Don't Be Strangers

2010-04-19T00:18:00.004+08:00

I joined CS3216 because I was looking for a good simulation of a startup environment.

I think much of my school life has been about simulations. I created a debate club because I wanted to simulate leadership - especially against rabid school opposition; I played Judo because it was a good simulation for pain. I'm not sure if they're perfect simulations, but I try. And so - for my application to 3216 I wrote:

This is probably the only time in my life where I may learn the realities of a startup without the threat of monetary failure, and I must admit that I was saddened when you told us that this would be the last 3216 offered in NUS. I originally planned to wait a year before applying; I believed I would’ve been a better programmer then.

But I'll say it: CS3216 has been an amazing simulation.

I am supposed to tell you about what I've learned from CS3216, but I'm not sure how to do that without sounding corny, or staid, or weird. So ... let me tell you a couple of stories.

Networking should be immediate
The night after the entrepreneurship lecture I hunkered down at PL6 to take a stab at Sportup's design. (It was a wasted night - nobody liked the design and so I had to start from scratch a couple of days later ... but anyway). Sometime after 11 Tomithy came in, bringing food with him, and he sat down with a whole stack of name cards in front of him. "What are you doing?" I asked.

"Emailing." he answered.

And so he did: I glanced over now and then, and he was shooting off emails to the people he'd met at the entrepreneurship session. I thought to myself: now this is something I've got to learn to do.

But of course I didn't email the people I talked to that night, and of course I didn't get anywhere on that. This must change, of course, and soon. (An aside: Toms is amazing. Did you guys see how brilliantly Supremacy was executed?)

Chemistry is difficult
I have to be honest here: I made a couple of big mistakes in CS3216.

The first, and biggest, was to choose the wrong teammate. Now I'm not sure if wrong really means ... 'wrong'. I believe 'wrong' really means 'wrong for me', or 'wrong for us.' It could be that a hundred and one things got in the way, and I just didn't make the effort to make sure we were on the same page. But if I'm honest with myself: I think now that we shouldn't have worked on the same projects. We'd have saved each other a lot of heartache that way.

I have learnt that chemistry matters - and it can be impossible, sometimes, if you've got the wrong mixture. Our personalities were direct opposites, and we came from completely different world-views. I think, on one level, I should've stepped back and let him find a better, more suitable teammate. But on another, it's good that I've learned this now - in the simulated environment that is 3216; better here than in the real world, with an actual startup.

Some relationships just won't work out - the trick is to figure out which.

Things came to a head between the two of us, the night leading up to the final project presentation. We were in COM1, and we were ... loud in our disagreements with each other. So I went downstairs, to vent to Orry and Hung. And the advice they gave - they were amazing.

"This isn't a problem about design," Orry said, "It's about something else. Something bigger. You've got to figure that out before you attempt to fix it -"

"But there's no time!" I said.

"Yes, there's no time." Orry said, and there was pity in his voice. I slumped in my seat.

I'm not sure what I could have done differently. Working on a project in CS3216 is a little like marriage - and if you pick the wrong partner, no matter how hard you work at it, you're doomed, rather, to fail. And that's a humbling thought.

I wish I could've gone back to change this - all I have now are apologies to my teammate, and that's not much.

Beware the Dunning-Kruger Effect
I got my first taste of the Dunning-Kruger effect this semester, and I'll keep that in mind the next time I work on another high-stakes project.

Learn to stay focused
This from Hung, on my teammate problem: "I think one thing is that your design isn't fast enough. Like - I can't worry about (Supremacy's) design - because I've got so many other things to do. But he could, because he was so far ahead than where you were. You were slow with the design. I think ... I think it's because you're not focused enough. You can get very distracted sometimes. This is not something you can change immediately. It takes time. Slowly, perhaps."

Hung is right.

Derive arguments from first principles
Prof actually attacked me for some of my essays. Lesson learnt: derive arguments from first principles. I'm still trying to figure this out, because some arguments are too big, and too intricate that deriving them from first principles would take a whole book (e.g.: the argument that fairness is objective takes 100 pages of intricately argued logic), but this is, I think, a principle worth holding on to.

I am thankful for this - too many of my essays, when I look back on them, have jumps in logic that are clear to me, but not to an average reader.

An algorithm for taking criticism
Having your professor attacking you for your own good was tough, but from that experience I think I've finally figured out how to take criticism, and it goes something like this:

Upon receiving criticism, determine if a) person means well (wants you/your app to improve) or b) person does not mean well.

If b) disregard criticism.

If a), filter for two kinds of information: valid points and invalid points. Invalid points are points where you know the critic is wrong - for instance, if he/she is assuming prior experience that is completely different from your past experience - ignore this. Do not get defensive. Nobody knows your personality as well as you do, and in the course of giving advice, the person is likely to get several things wrong about you. This is normal.

Focus on valid points. Ask for (impartial!) third party opinion, from people who know you well enough.

Absorb valid points.

Thank critic.

There are different kinds of motivation. Star Wars will never be the same again.
I've a feeling Prof really likes Star Wars. He thinks he is better looking than Yoda (though Yoda is kinda cute). Okay wait, that wasn't the point I was trying to make.

The point is this: motivations matter. For the longest time ever I was motivated by ... I don't know, really. Wanting to prove detractors wrong. Or wanting to prove myself to myself. Prof said this was bad. Much of his advice on the matter was shrouded in geeky metaphors like the 'dark side' and the 'way of the force', but he was making an important point. Motivations matter - and some are inherently better than others. I will be leaving CS3216 thinking about my motivations, and I'm not sure about the answers I may find.

I'll pray about that. And I'm fairly certain I'll find answers, sooner or later.

Doubt is normal
Doubt is okay. It is normal.

I stayed up nights wondering if I was on to something on Treehouse (I'm still not sure). I delayed launching Pandamian for a full year because I thought it was going to be disruptive to the publishing industry - too disruptive for a 20 year old to launch on his own. CS3216 has taught me that it's okay to doubt - and I learnt this from talking to Kah Hong, to Reuben (who himself was doubtful over Voucherous). It's cool to know that there are other people out there who also doubt, who also fear. I think - when Pandamian launches, one of the first things I'll have to do is to set up some kind of informal support system between founders - because the doubt, the stress, can really be too much for one person to bear.

But I'm not sure, of course. Too many things can happen, and there's no telling how things would be like even a couple months down the road. What I do know is this: if you're going to start a startup, do it with someone else. The doubt can be overpowering otherwise. That's a valuable lesson indeed.

And, lastly:

"Don't be strangers, when you see each other in school, in the future. I wish you the very best."

Don't be strangers
'Don't be strangers' was probably the last thing Prof said to us after the poster session. Looking back on the course, I now realize that the people I'm closest to are the ones with whom I've pulled all-nighters/spent long periods together with. Kah Hong has been a real blessing, in terms of support, and he's one of the few people in the class who has a real sense for 'what users want'. I've spent nights in COM1 with Orry, and Hung, talking about all sorts of weird things. But I think this connection applies to everyone in the class. There are too many other people with whom I can now nod at - in the hallways, the biz canteen - and know that we've shared a semester of pain together - and survived.

I entered CS3216 alone, and left with friends. And I can only be thankful for that.

Onward.

Liveblogging the Last Lecture

2010-04-12T20:39:00.001+08:00

The class is full, and there are extra people attending the last lecture. Lots of people milling about, joking, doing very 3216-community things.

We start off with a short pitch by the guy behind Mobiwerkz. If you want to join, and you're interested, go email him.

7:00 Watched a video

7:05 Everyone jolly well go and write blog entry, to tell what the heck you learnt. Crowd sourced to score people our blogs. Clever bastard.

7:07 "So it's all your fault!" Big grin.

7:08 To Shannon's suggestion that everyone puts a 10 for everything: "But that won't work! Why? ... Exactly! Prisoners dilemma!"

7:12 (Blogger's note): Oh great. I have a word limit.

7:13 Remember "Wong Lim Soon!" And, yes, he's the prof that determines everything.

7:14 Sales matters

7:15 People matters. Whoever you actually work with matters. (Oh yes, definitely.)

7:16 Execution really matters. The execution has not been fantastic this semester. And there's a picture of a bunch of kids climbing a tree. So there's two things about execution: 1) try random stuff 2) keep trying. And then there's working on the problem, and listen to people. Listen to prof. Which is a balance between being stubborn and sticking to your principles, and listening to people giving advice.

7:17 So there are many paths to success.

7:20 Anybody want to go back? Got a hot date to go home? (A couple seconds later) No? So I shall now indulge in my favourite past-time: preaching to students.

7:23 I'm not a psychologist, period, but I try to observe things, and derive conclusions, and what I've seen is that nature sets the limit on what you can achieve. This is what ... I've seen.

The nurture part determines whether you can achieve it.

7:24 So the truth of the matter is none of you can be a Tiger Woods. The golf arr, not the sex! /uproarious laughter.

7:25 There are two things. There's nature, and there's nurture. And sometimes life's not fair.

Some people complain too much. The good news is that most people's capacities to achieve is much much higher than what they actually achieve.

So that gives me a job.

7:28 Attitude. Ultimately, what I hope to do in this class is to fix mindsets. (Insert section about Jolly Good Fellow engineer in Google, and talking to them, and finding out how to think.)

7:32 A lot of people are poor because their minds can only handle so much money. They are programmed to be poor. Quote from Secrets of the Millionaire Mind. You agree, don't agree?

7:34 Yanjie disagrees. Toms says that it's not particularly concrete. Prof steps in: "Nature nurture rubbish again."

7:36 Generally, however, Prof thinks this is true.

7:37 "Give a poor guy 100k, and at the end of 10 months he was a lot worse than when he started off."

7:39 How you perceive the world really matters. Research has shown that optimists are more likely to succeed than pessimists by a long shot.

7:41 I believe education has three things. 1. Find direction, 2. Fulfill their potential 3. Become good people

This whole thing, however, has this big 'It Depends'.

7:45 Confucius says: self, family, country, world. There are these things that he says. Then he says, you figure out how to govern yourself, then you figure out how to help your family, then you figure out how to serve your country, then you 'attempt to bring peace to the world.' To change the world.

Self
7:47 Learn to like yourself. To be at peace at yourself. To be okay with the way you're born. There are people with some deep-seated insecurities. Know what you're capable of, what you're good at, focus your strengths, and outsource your weaknesses.

4:58 Delegate - you can delegate responsibility, but you can never delegate accountability.

4:49 Deal with fatal flaws. And the worst fatal flaw is laziness.

[Though there's this military quote: "I divide officers into four classes -- the clever, the lazy, the stupid and the industrious. Each officer possesses at least two of these qualities. Those who are clever and industrious are fitted for the high staff appointments. Use can be made of those who are stupid and lazy. The man who is clever and lazy is fit for the very highest commands. He has the temperament and the requisite nerves to deal with all situations. But whoever is stupid and industrious must be removed immediately." - Attributed, circa 1933; General Baron Kurt von Hammerstein-Equord (1878-1943); German Chief of Army Command (1930-33)]

7:50 Take personal responsibility (or - jokingly - find a religion and blame God).

Failures come from two sources. One is it's your own fault. And the second one is ... act of God. That's life. Bo pien.

7:52 Stay teachable. Try to keep learning. And try to learn new things. Prof praises Reuben and Ryan, for posting new things, because they keep reading new things. They read, he reads.

7:54 You're less important than you think. Do not to be too concerned about how you look. People won't remember you.

7:56 Actually I have a problem now. Now I've taught for four years, and I can still remember all of you. But in one or two years, I will have to start to garbage collect.

7:57 10,000 hours - it turns out that I've done 10,000 hours of teaching. But I don't want to. 20,000 hours.

7:58 The char kuay tiaw experiment: go out one day and cook, without my skills, to see if it's possible to make a living without an education. And I think I can make more money than as a prof.

7:59 I am better than I was yesterday. Quoted for truth, hopefully dy/dx > 0; but nature limits you. But remember that the limit is an asymptote. You can't reach it - so as long as you keep getting better, it will be okay.

8:00 There is no substitute for hard work.

"So part of the thing to do as a lecturer is to make sure nobody dare to sleep"

Hehehe.

Family
8:01 If you marry the wrong person, you. Are. Screwed. Photo of Ris Low appears on screen. /laughter

8:03 "So what qualities are there for a spouse?" Pause. "From experience?" *Laughter*

Prof looks at us. "It depends."

8:04 The girl that's right for him (points to Reuben) is probably not the girl who's right for him (points to Adhiraj). Sorry I sounded like a scientist, because I am.

8:05 For the first few months of being in love, there's a chemical in your brain called PEA that makes you high - typically lasts six months to a year. Then it wears out. So the moral of the story is: don't marry someone in six months. There are people who marry and get it right ... but who feels lucky today?

8:06 Right time to marry is when she 'feels like family'. So there's a probability that she won't be sexy forever. One kid still okay, two kids a bit cannot make. /uproar and then pause. Oh you mean you recorded me ahh? Die lorr.

8:07 Be careful about these things, because it's not so simple. For Christians, look for the Proverbs 31 girl. And, err, girls don't look for the Proverbs 31 guy. Because otherwise he doesn't do anything.

8:10 So there's this story about a guy walking through a field, and he was asked to pick the tallest head of corn. And he came out empty-handed. Then he was brought to a forest, and told to chop down a tree and bring it our (that is smallest and can be brought out) and he came out with this puny little thing. And that is love.

8:11 Not easy wan la. If you can find an algorithm to solve this, you'll be very rich (Shannon behind me says: there's this episode of How I Met Your Mother ...)

8:12 Don't do a Jack Neo. (Class laughs). So that brings me back to Character vs Reputations. Typically character implies reputation. But reputation is not if and only if. So people with good reputation may not mean good character.

Country
8:14 Skip the government bit. Because it's Singapore.

The World
8:14 Think. Now here are a couple of articles that I've taken from the Strait Times.

/shows an article from ST about this guy who is a top chef. So this guy is a gifted chef. And he probably makes money than you do. The thing is, do what you're good at. If this guy tries to be a prof, he will sure die.

8:17 Shows a picture of Thailand. They're a failed state now. A bit sad. But why are they fighting? Class says it's red shirts vs yellow shirts. So Singapore doesn't allow protests. And it's complicated. They're arguing about human rights, but they may not know what they're talking about. So they have to think. Think. Things are not so simple.

8:18 Shows a picture of this 50 year old guy, who's unemployed, headlines: where are the missing fifties? And the times are changing - during your grandfathers time, when you have a degree it's a big thing, you're set for life. And when you get hired. you'll be taken care of by the company.

So what has changed?

8:20 Too many people have degrees. So what has changed hasn't been about the degree. If you're useful, you'll get hired. If not, you have pretty degrees, but you'll 'die die never get hired'.

8:24 In order not to loose your job at 60, just be damn useful. That is the best thing you can do.

8:25 A few words on the stock market. So the stock market has been rising. And this has been happening since the industrial revolution because the people have been putting their retirement money into the stock market.

So are stock markets going to be rising all the time?

Not sure. You can't base it on past performance. But there's going to be huge demographic changes. Where the bottom constricts. And the top (old people)expands.

8:27 If it's too good to be true, it probably is. Small smiley face with a label: "Ponzi Schemes."

8:28 You cannot achieve superior outcomes in education without the teachers. So I realize something that I haven't done so in the past, and that is to encourage my students to become a teacher.

The thing about teaching is that it doesn't play very well. But it does pay okay in Singapore. So consider it.

8:29 I can't tell you what's going to happen in the future. With 3216, that is. So there's going to be two courses. And semester 1 will be 3215. Which is SoC only, basically to train up the software engineering part. And for semester 2, we'll absorb all the non technical people. So most of the technical learning would be done. If any of you have good ideas on how this is to be done, please contact me.

8:31 Long term goal is to produce 60 students of this calibre. And ... I don't really know how it'll be.

8:32 So if you can't remember a thing from this lecture, take this: figure out what you like, AND you are good at ... and just f*cking do it. Because there has to be a balance between liking it and being good at it.

8:34 Do the right thing. I think in life, there will come a point in time where there are two options. One option is to do the more profitable thing, and the other option is to do the right thing. Sometimes you don't know. And if you don't know, and you just do, it's okay. But if you know there is a choice ... then I want to encourage you to do the right thing.

And doing the right thing usually has a cost. And sometimes you don't even feel shiok. Most times, in fact, you will pay. But ... doing the right thing typically, as Randy Pausch says: the 'karma will take care of itself.' And while that's a very buddhist thing, it's the truth.

8:36 I'd like to thank my teaching staff. /applause

8:37 ... and this is for you. *shows slide with image of book titled 'Common Sense'* There are many problems in the world, and a lot of people don't have common sense. And I think a lot of it has to do with ... being curious about the world. To gain common sense, that is.

8:38 And so, with that, I wish you all the very best for Wednesday. And this is the end ... but it's also the beginning. Thank you very much.

How To Do UI Design, In 8 Easy Steps

2010-04-08T01:40:00.001+08:00

When Prof Ben asked us what workshop we think should've been included, in the mid-term feedback, I remember leaving the field blank because I couldn't think of anything to write. I now regret that decision. In the past couple of days I have come to realize that people don't understand the underlying mechanics of design. I have been embroiled in a two-day-long argument with what to do about Sportup's look, and I think it would do to explain some of the most basic principles here, on this blog, once and for all. I hope this would be of some help to you; if it doesn't make sense - feel free to shoot me an email, or a comment if you're so inclined.

What Is Design?
Design is how your users interact with your product. That's all there is to it. Simple as pie.

Now, there are two misconceptions about design that I want to clear up immediately: hopefully for the first and last time. The first misconception is that good design has to be pretty. The second misconception is that good designers have an innate feel for beauty, and so therefore design by sitting in front of the computers and working until something feels just right. It does not. They don't. Design isn't some wishy-washy thing that people with easels and paintbrushes tucked behind their ears waste their time indulging in. It is as much a science as it is an art, and with computers - the field of study that is related to design is called Human Computer Interaction. There are principles in HCI, just as there are principles in software engineering, and the results for breaking them are the same in both: you end up with an unusable app. What are they? I'll come to that in a bit. But before I do so, let's talk a little about the two misconceptions:

Misconception 1: Good design must look pretty
You may not believe me on this, so let me show you a couple of things, to make you understand.

The Drudge Report broke the news on Bill Clinton's affair, and till this day continues to exist with the exact same design it had back when it was first created. Jason Fried of 37signals calls it one of the best designs he has ever seen, and wrote a 1000 word article on why he believed it to be so.

Jakob Nielsen is the world's leading authority on web usability and design. His site looks like a piece of shit. But when you're there, you find something odd happening: you know immediately where to go, what to read, and where you are on the site at any point in time. Nielsen's site has good design.

In 2005, Blogger contracted Douglas Bowman of Stopdesign to create and implement a host of themes that are still in use today. Of those designs, Bowman created one that is almost universally lauded as timeless: a simple, bland, minimalistic theme he named Minima, the same theme I'm currently using on this blog. Why is Minima considered good design? Simple: it's used by hundreds of Blogger blogs, all over the world, for all kinds of topics, by all kinds of people. It is timeless. Ugly? Yes. But good design all the same.

Still not convinced? Well, consider this: when Paul Graham built Hacker News, he purposely chose a garish colour and a sparse, ugly design. He made the site for programmers to use, and he wanted to discourage all other kinds of people from joining the site (and therefore the discussions). Hacker News is today one of the few online communities with a consistently high level of intelligent commentary, and this is by no means an accident: Graham's built all sorts of clever design hacks into it to encourage just this level of discourse. Ugly it may be, but bad design it is not - HN's look does its job, and does its job well.

Now you're probably going to say - sure, dude, use bad design when you want to attract programmers (who don't have a sense of design anyway) ... but when you're building for the real world you have to look pretty! Really? Wrong. Two of the most successful sites ever built on the Internet have been based on particularly weak aesthetic foundations, and if you don't believe me, take a long, hard look at a) the Google home page, and b) Craigslist.

Misconception 2: Designers design by feeling.
They do not. I'm not going to lie and tell you that designers are as hard-assed about logic and testing as programmers are, but on the other hand they're not some sculptor who plays with clay and goes through a thousand iterations before they finally find the inspiration to make 'the one'.

If you're working with a good designer, anyone who's done some outside work before, you'd know this. When I was in 9rules I complained to Mike Rundle, the designer-in-chief in charge of the site's overall look and feel, and he told me to wait awhile, to see if things changed. And it did. Mike's original design didn't feel right, but over time I grew to love the way the site worked, the way it felt. The 9rules community is, to this day, one of the best things that has ever happened to me online.

Designers who know their stuff work around several universal principles. When I visit sites with friends, I often hear them complain about this design or that design, saying things like: "Oh that's just ugly. How did she get so successful?" or "I think I can design better than that."

What they don't get is the simple truth: they can't. And why? Well, that's simple too - they're missing the point. Design isn't about aesthetics. It isn't even about choosing the right colours. Design is - at its very core - about building the right things the right way, and doing it in a manner that is befitting of the user.

Everything else is secondary. Even looking pretty is secondary. A user who can't use your site isn't a user at all - he's just a statistic. Here and gone in the blink of an eye. I should know - I've gotten plenty of those in the four years I've run my sites.

Eight Simple Steps To Good (Web) Design
As the title says, here are eight things that are pretty much universally true. I hope they do you some good.

1. Get their attention. Period.
This isn't true for most of HCI (which is concerned with the design and implementation of computer interfaces) but it is true of the web.

Internet users are fickle-minded people. Most visitors you'll get to your site will stay around for no more than 3 seconds, tops. The trick is to get them to pause - even for a little while.

Everything you'll learn about webdesign is built around the central philosophy of getting. People. To. Stick Around. For Awhile.

Get that into your heads. I spent four years figuring these things out, I'd only wish I'd learnt it earlier.

2. Important things above the fold.
The fold is what you see when you load a web page, and you don't scroll down. (Anything you have to scroll down to see isn't above the fold.

The term originated when newspapers ~~still existed~~ were first introduced. The fold used to be the top part of the front page - the bit that shows when it's folded in half and on a newsstand. Ads above the fold sold for twice the amount of money that of ads below the fold, and for good reason - those ads (and the headlines) were the first thing a prospective newspaper reader sees.

3. Keep to the left.
There is irrefutable evidence that users pay more attention to elements placed on the left side of a webpage as opposed to the right side. In fact, the actual figures are 69% (of attention) to the left, and 30% to the right. When designing a web page, place the most important elements to the left of the page. This is one reason why so many sites place their copy to the left - it gets more attention, and therefore makes it easier for the reader to understand what the site's all about.

Keep to the left for important content, you'll have far less trouble otherwise.

4. Design to the F

A direct implication of steps 2 and 3 is that the most important content should be placed on the 'F' of attention.

Users view websites according to an 'F'. Design in anticipation of the 'F' and you'll find that - oddly enough - users would know where to go and how to find things. Sites that employ the 'F' to their advantage are often described as intuitive, simple, easy-to-use. Use Facebook? Take a look at the current redesign. Where are the most important functions located?

To the left, and to the top, correct? That is the 'F' of attention right there, in action, acting right under our noses.

5. Understand visual importance
Visual importance is a little hard to understand. One of the simplest examples is that of colour. If you've got something small, and placed to the very right of the page (far out from the 'F' of attention) how are you supposed to draw attention to it?

One simple way is to use colour to your advantage. Colour it in with a brighter colour and you'll compensate for the element's position on the page.

Visual importance gets a lot more complex than this, though, and a lot of it is subtle stuff like rounded borders and smooth gradients (and the kinds of emotional responses they get out of you). If you've read this far, and you're interested in becoming a good designer, I'd recommend Andy Rutledge as a starting point. (Psst: read his post on design gestalts).

6. Keep things lean.
Choose a good width for your content. Wider content is harder to read. The optimal width, I have found, is 500-600 pixels. Any wider and you'll have to adjust by increasing your font size.

Don't believe me? Grab a nearby book. Chances are that there aren't more than 20 words on a single line. There's a reason for that - it turns out that a reader's attention tends to drift away the longer and denser the line is. I can't remember where I first learned this - but it's a principle I apply to all the writers who come to Novelr for design advice. Want to use long text widths? Then increase your font size - you'll have less words per line than you would if you didn't, otherwise.

(For the curious types: here's an article on the phenomenon.)

7. Use less columns
This depends largely on whether you're interested in being read. I'll admit here that this doesn't apply to most webapps, but if you're designing a text-heavy interface (such as a blog, or an ... Argo,) you'd do well to control the number of columns that appear on any one page.

User attention is split by number of columns. The more equal-width columns, the more distracted the user becomes. The solution is to either cut down on the number of columns your site employs, or to subtly emphasize relative importance using visual cues like shape and colour. How? Don't look at me - go out and experiment for yourselves. And that, perhaps, leads me to 8:

8. Test a lot. Use good tools.
... because that's the only way to know if the design's just right for you. Good tools, you ask? I personally enjoy Clicktale, and Crazy Egg. Though analytics and plain vanilla user testing works just as well too.

Good design is timeless design, and timeless design takes time (pun intended). I've only done one so far, and I'm still largely hit-and-miss with my work.

But I intend to get better at it. And if you're working with a designer who knows his stuff? Please, please stay out of his hair. He knows what he's doing, and feedback is good; but please - try to be fair.

Quick Thoughts on DuckDuckGo

2010-03-25T08:35:00.001+08:00

DuckDuckGo is a search engine. It is a Google competitor. Which also makes it a Bing competitor. Currently, it is a better decision-engine than Bing, and it's rather more useful than Google for certain search terms.

Someone once pointed out that if a search engine were to be built on good design, with a focus on making search results easier to absorb, they'd be able to compete with Google on a more-or-less even scale. DuckDuckGo seems to be doing just that, and I think they're doing it pretty well.

The most amazing thing about it, however, has been that it's all self-funded. And the dude's even responding to feature requests on Hacker News. (He implies that the entire search engine's a one-man show - by that I mean that he says "[Duck Duck Go] is a complicated mashup of my (emphasis added) index/crawler, structured crawls/dumps from crowd-source sites, live vertical APIs, and highly modified BOSS (edited, re-ranked, merged, omitted, etc.))

I think an acquisition seems likely. Still, gotta admire the balls on this entrepreneur for taking Google head-on.

Update: DuckDuckGo's results page for CS3216. Never knew CS3216 was a chemical compound! Hrmm!

Update 2: See searches for Java, Microsoft, and iPad.

Work Work

2010-03-24T12:07:00.001+08:00

Henry graciously offered to give us a lift back to our residences, and so Adhi and I are in the car, talking.

"You know the irony is that the weekends are less free than the weekdays?" Adhi is saying, waving his hands in the front seat, "On the weekends we have to do this, but on the weekdays it's less busy because we have other modules to worry about. Now what kind of twisted logic is that?"

I murmur my agreement. We had just spend the evening discussing our app's implementation and there was still a lot of work to do.

"Sometimes I wish we had extra hours in the day." Adhi continues. I see Henry smiling in the rear view mirror as he turns the car past the Mochtar Riady building - we're only minutes away from the bus terminal, now.

"But why just extra hours?" I say. "You know, there's this comic called Dragon Ball, and there used to be a room in the comic where one minute is one hour, or something like that. I sometimes wonder what it'd be like to have that room - imagine preparing for your exams 20 minutes before the paper, or even 5 minutes ..."

"Sure from Dragon Ball?" Henry asks. "Sounds like something from siaw ting tang."

"Yeah sure." I say, and then to Adhiraj: "But why would you want extra hours? Why have hours when you can have days?"

"Oh no, that won't work." Adhi says, "We'll still have only two free days per week."

"What? Wait ... why?"

Adhi turns round to look at me. "Because NUS would take away the extra days from us." he says, in all seriousness. "They'll take that for themselves and just leave us with the two normal weekend days to relax."

I pause.

"Damn, you're right."

"Uhhuh."

"You're absolutely right."

And so, with that disturbing thought in our heads, we left the car and walked to our rooms and got right back to work.

Meritocracy

2010-03-16T16:31:00.001+08:00

I have a sit-in lab to prepare for, so I must keep this short. Two things.

First I must say that I loved Zit Seng's presentation on web performance, despite having a runny nose throughout a large part of it. While I didn't understand most of what he was talking about, I did, more or less, get the general feel of how hard keeping servers up and running actually are in the real world. I think it was halfway through the presentation that I turned around to ask Kah Hong if he had experience in any of this, and he said no, and I pointed out that every time sgBeat's server crashed his mum would be the one to get it up and running again. He chuckled at that.

(I must also say - as a Mac user in NUS - that Zit Seng's blog is an invaluable resource on how to connect, print, and pretty much configure your Mac to work with SoC/NUS related assets. I don't know how I could've survived my first sem without him. The guy is just plain brilliant.)

Second, I rather enjoyed Prof's session on "Grades, Scholarships and Meritocracy". I didn't have much to say throughout the lecture, simply because there wasn't much I disagreed with. (Well, it was either that or I didn't have much interest in how Singapore manages its scholarship allocation.) After the lecture Tomithy asked how I was going to respond to Prof's arguments, but the truth is that there isn't much argument to be had. Our discussion (of which the first few comments have disappeared, due to a bug in Blogger) was primarily centered around the causes for a declining importance in grades.

What struck me the most has been that this session even existed. 50 years ago the advice would've been: "get good grades and you get a good job. Period." Today the advice is: "grades are important only for your first job." Could there be another decrease, 50 years down the road? I am convinced that there would be, but to what I am not particularly sure. I believe it would be really interesting to find out.

One last point, on meritocracy.

I am a big supporter of meritocracy, because I believe it works. It is clear, too, that Singapore is one of the ideology's most fervent worshippers. But in order to play with meritocracy, in order to live with it, it would do to examine some of its larger flaws.

What is meritocracy, in its purest form? Meritocracy essentially says that if you have talent and drive, you would and should rise to the top. But it also implies that those who are at the bottom, deserve to be at the bottom, and should stay there so long as they deserve it. It implies that our failures are merited and deserved the same way our successes are merited and deserved.

In the middle ages, when you met a poor person, that person would be described as 'an unfortunate'. Literally - an unfortunate; a person who has not been blessed by fortune. Today - and particularly in meritocratic societies such as in the US and in Singapore - such a person might be more unkindly described as a 'loser'.^[1]

Alain de Botton points to Emile Durkheim, whose work in sociology shows us that such thinking leads to increased rates of suicide. "There are more suicides in developed individualistic countries than in any other part of the world." he says, "And some of the reason for that is that people take what happens to them extremely personally. The own their success. But they also own their failure."

When people say that many Singaporeans are unhappy, we should recognize that this is a net effect of meritocracy in action. The members of a meritocratic society are told that they can be whatever they want so long as they have the talent and ability to do so. When the reality doesn't reflect this ideal, people become very rapidly anxious, and envious, and just largely unhappy with life.

Perhaps it would be less of a problem if the reality reflected the ideals proposed by meritocracy. But this cannot ever be true: the reality is that there are too many random factors: there are accidents of birth, illnesses, freak explosions, and so on so forth, to truly reward people according to their merit. I have a friend in my cluster who has probably more business sense than most of my cohort combined. He is a fourth year student; very interested in entrepreneurship, but he is honest with himself. His parents are unwell. He would probably have to work at a job in order to take care of them.

A somewhat related idea that we now hold today is that we are told that we - and only we - are in control of our destinies. This is ridiculous, of course. There is as much probability of you becoming the next Bill Gates as there is of a peasant farmer becoming royalty back in the 1800s, in England (Botton uses the example of the French aristocracy). The difference is that today it isn't made to feel that way. We are told that we can go out and do whatever, be whoever we want to be, because of meritocracy, and this isn't always true.

There was a paradox in last night's session, and I'm not sure if many of us noticed it. Prof talked about meritocracy in the third part of his lecture. But he also mentioned that life is inherently unfair. What we seem to forget is that the two ideas are diametrically opposed to each other. While meritocracy is a beautiful philosophy, we must also be honest about its failings - there is no such thing as a perfectly meritocratic society. It is impossible. We just like to think that it isn't.

Meritocracy is mankind's finger at the face of life's unfairness, and if we think about it carefully: life usually wins.

How you deal with all that unfairness is up to you. Historically speaking, mankind's solution has been to turn to religion. In religion you are told that you are not always responsible for your failures: that sometimes, due to accidents of birth, or luck, or happenstance, you fail and it is not your fault. That is the kinder view of things, and it is one that I subscribe to; there may be others, of course.

I am not suggesting that we scrap meritocracy altogether. I am a big believer in the ideals of meritocracy. I think it is the best thing we've got, barring all alternatives. I am however arguing that we must be honest with ourselves. Meritocracy isn't a perfect ideology, there are problems with it, and those problems are often what leads us to become a deeply unhappy people.

^1. Adapted from Alain de Botton's TED talk.↩

{Essay} Why Grades?

2010-03-14T02:13:00.001+08:00

Cross posted from my personal blog. The {Essay} tag that I use denotes at least a week of research and thought; minimally, also one round of editing. Do note, too, that this was originally written for a Malaysian audience.

Do grades matter as much as our parents say they do?

One thing we know for sure is that grades are important. Our parents reward us when we ace exams, and so we have been conditioned to think that scoring As in school are important achievements worthy of our time. And for the most part, this is true: the approval of our peers and our parents and our teachers depend largely on our grades. So grades do matter. But there's an interesting assumption to examine here: why do grades matter so much? Are they still as important now as they were 50 years ago? And perhaps - more importantly - why do so many of us accept grades as the de facto indicator of ability, without ever questioning the underlying logic of our grading systems?

I've been thinking about these questions for some time now, and I think I've come to some reasonable conclusions about them. My contention is that grades are no longer as important as they once were, and the implications from this idea are rather exciting, and scary, both at once.

Where Exams Come From
Exams and grades are relatively new things to the human experience. It wasn't until the industrial age that schools - and by extension exams - became commonplace.

The first society to implement examinations were the Chinese. Beginning with the Sui dynasty, candidates from all over China would gather to take the Imperial examinations, held once a year, every year, in order to gain entrance to the state bureaucracy.

There are two important things about exams that we must recognize began with the Chinese Imperial examinations.

The first is that the Chinese examinations served as a filter for the Imperial government. They made no pretense to be anything otherwise. And to this day exams still do act as filters: there are only so many jobs in companies and governments, and so therefore there must be a way of separating the good from the bad, the capable from the uncapable. Exams are that 'way', and they serve exactly that purpose.

The second thing may surprise you, and it is this: what the Imperialist Examinations focused on were Confucian classics. You may wonder at that, and rightly so: what does a study of the classics have to do with state management? And the truthful answer is ... well, not much. Apparently the Chinese government thought very highly of it - they considered learning the classics to be a good sign of intelligence, and if you excelled at it then you must certainly be clever enough to manage a state on your own.

Was that a valid idea? I think there's something to it - the British colonialists had a remarkably similar mentality. Do well in Latin, they say, and we'll give you a colony to rule over for us. And that worked out pretty well for them.

Where Exams Go Wrong
Those base assumptions that the Chinese Imperialists had are things that we've carried with us, even to this day. Exams are supposed to be good filters, and they are supposed to be indicative of our ability - even if 80% of what we study would never be used in our actual jobs.

But is this true?

If exams are good filters of society - how, then, do we explain the many people who do well in school, but not as well in life? And how are we to explain away the weird outliers that defy what we know of examinations - Steve Jobs, for instance, or Bill Gates, or Richard Branson? If exams are good filters, these outliers shouldn't have had happened in the first place. And if they really are good filters, everyone who scored good grades would be just as successful outside of school as they were in it.

We know that some straight-A students make for terrible employees; why is that so?

Perhaps a better question to ask is this: what exactly is it that grades measure? If exams are a filter for weeding out the good from the poor, then surely there must be something that they measure that's so valuable to future employers. If you could figure that out, perhaps you'd be able to get more mileage from your examinations.

I suspect Paul Graham has the best answer to that question: grades measure future performance. Employers are interested in future performance. They can't test everyone themselves, by putting people in the job one by one until they find the best guy, and so they rely on the next best thing - grades.

But the problem with grades is that grades aren't always a good indicator of future performance. In fact, they can sometimes be particularly bad. Grades are the results of exams; exams are a filtering system for future performance, and so therefore exams - being a system, like all systems - can be hacked.

How can exams be hacked? By its very nature, exams are particularly susceptible to people who are good at ... well, exams. In Malaysia, scoring well in exams is usually a direct function of one's ability to absorb certain facts in order to vomit them out later onto a test paper. If a student gained the skill to do exactly that - he would do well for all his exams, regardless of whether the exam was history or chemistry or math. And, yes, you'd think this would be different for subjects like math or physics, where there's thinking involved, but you'd be surprised. I remember being shocked when I first came to NUS. My discrete math teacher was a Frenchman, and the math he taught required creativity - something I had never experienced before. It was amazing and beautiful to see that coming out from a high-level math textbook, and also rather scary; scary because it wasn't particularly hackable.

Is it really a problem that grades are not good indicators of future performance? The answer to that is yes, it is - because it is no longer universally true that grades are the 'next best thing' for measuring performance. Grades were never a good indicator of future performance to start off with, and they are beginning to seem obsolete. What has changed?

The Decreasing Importance Of Grades
It would be wrong to say that companies have wised up to the inaccuracy of grades. For the large part, this change has been due to a shift in economics as opposed to a conscious, calculated decision by market leaders.

The global economy today favours smaller companies over big ones. There are many reasons for this, but the basic ones are obvious: due to globalization and cheaper logistics, it now makes more sense for companies to outsource some tasks in order to stay focused on their core competencies. This has been a relatively new phenomenon. Never before has a smaller company been able to take on a bigger company - and win. If you don't believe me, consider: in the past, railways would purchase steel refineries to manufacture the steel required for their operations; today, it outsources such operations to external - often international - companies. And this is but one example, in what is a remarkably outdated industry. The effects are far stronger and more powerful in technological companies. But, bearing these differences, what does this mean for grades?

It turns out that it is easier to measure performance in a small company, as opposed to a big one. If you do well, the company does well; if you do badly, the company does badly. This is not so for large corporations. In a large corporation, individual performance cannot be easily measured, because the organization is so large that your individual contributions do not have a significant effect on the bottom line. Graham points out this is why grades have been so important to employers for the past few decades. The harder it is to measure individual performance, the more important it becomes to predict it. And because the economy has been dominated by large corporations for the past few decades, it used to mean everything to do well in exams.

But this is fast becoming history. Grades matter less when you can directly measure what they are made to predict - which is real performance. Why bother with an indicator when you can gauge the real thing? Larger corporations are adapting in order to enjoy the benefits of being small - Google, for instance, forms small teams of engineers to develop and test new products, and presumably gauges performance based on those smaller teams.

If this seems a little incredulous to you, consider: just 50 years ago it was enough to get good grades to get a good job to retire comfortably. This no longer holds true. Today, we are not only aware of people who have succeeded despite dropping out of college, but I have friends in NUS - in Singapore, even, a very exam-oriented country - who have either skipped college altogether, or who plan to drop out of school to do their own startups. And in big companies, there are now performance reviews, where before there were none. It used to be that seniority was all that mattered; young associates accepted a lower pay because they had to pay their dues, their times had yet to come.

It seems to be uncomfortably real that grades are beginning to decrease in importance. At the very least, they no longer hold the make-it-or-break-it quality they once had. And so, if this is true, the trend begs the question: what does this mean for our students?

An Exam-Oriented Paradox
One important thing we must remember is that for certain countries, the old model seems to hold true. In Japan and Korea, for instance, if you earned good grades, you are still able to score a stable, quality job in a salaried company. And to that end both countries have very competitive exam-oriented systems, and a high density of cram school to boot.

Would this state of affairs last forever? I doubt it. It turns out that smaller companies are also more efficient companies, and globalization cuts both ways. Sooner or later, the Korean and Japanese corporations would have to outsource their operations, and therefore split into smaller, independent units, if they are to keep up with more nimble competitors. And even if they refuse to do so, current economic forces make it feasible to start small companies, particularly those built around the Internet. While Asian countries currently enjoy the luxury of the sure grade and the stable job, it is something that may not last for much longer.

Unfortunately for us, however, the Asian model of education is still optimized for this old economic model. Malaysia isn't by far the only country with an exam-oriented society. There is nothing wrong with doing well in exams; it is when exams become the focus of a society's expectations that things begin to go wrong.

The problem with exams - particularly in Asian societies - is that the examination often becomes an ends onto itself. People say that the purpose of school is to learn new things that you may put to use good later in life, but this isn't true. What you're really going to school to learn - if you're in an Asian country - is to learn how to do well in exams.

There is a simple test for this: ask yourself if studying equals learning in high school. If it isn't, and you aren't doing much learning while you study, then there is a disconnect between the two. The truth is that schools spend a lot of time teaching us how to do well in exams. 50 years ago, this made a lot of sense, but today such time is better spent perfecting ideas that would come in handy in a performance-driven world.

In Malaysian high schools, for instance, we should stop pretending that the school is there to teach us good things. They are not. The Malaysian education system, from ages 6 - 19, is designed to teach you how to do well in exams. Learning math and science and all that jazz is secondary to that one core purpose. And this is - sadly - the truth of the matter; it is why we have tuition; it is also why we have shiny ads advertising 'exam-grade' pencils and erasers on television; all of it is what it means to live in an exam-oriented society.

Creativity
There is something that must be said here on creativity. For all the noise our education system makes about creative thinking, and critical thinking, their models of teaching such forms of thinking cannot be conceptually further away from the truth.

I began this essay by asking a series of interesting questions. I examined why grades mattered so much, why grades are so important to us, and why they may be irrelevant to a reasonable assessment of success in the real world. There is one question, however, that I have neglected to answer, and that is: why do so many of us accept grades as the de facto indicator of ability, without ever questioning the underlying logic of our grading systems? I believe this to be the most important question of them all.

One reason for this may be that we have been conditioned to think, since young, that grades are the be-all and end-all of our childhood existences. But there comes a point in time in which we are old enough and wise enough to challenge our own assumptions. So now the question: why do so few of us challenge this assumption in the first place?

I suspect the main reason for this is that we are taught, since young, not to think for ourselves. We don't hear that outright, of course. No teacher actually tells us not to think for ourselves. What they do tell us, however, that has the same net effect as telling us not to think, are things like "That's very good dear, but it's not what the examiners are looking for" or "That's not a proper exam answer". I suspect that each time our teachers tell our children that, they lose the ability to think laterally, to think critically, and so gradually they don't bother to think in terms of truth at all.

End
Grades are important as measures of cognitive ability. But do grades matter as much as our parents say they do? The truthful answer is that no, they don't, not anymore. Grades don't matter as much as real-world performance does, and as it becomes easier to measure performance directly, grades will matter less and less.

But is this an excuse, then, to score bad grades? The truthful answer is that I don't know. It probably depends. It is certainly a better use of your time to go out and build things, and learn things, as opposed to spending all that time learning to score well in exams - a skill with admittedly little real-world application. But on the flip side of that coin, grades - and by extension exams - are important elements in the learning processes of our education systems. It feels like a cop-out to take such a stance after 3000 words or so of argument, but this is the truth. Just be sure that you are studying for the sake of learning, and that exams are an indicator of that learning; and not the other way around.

Sometimes

2010-03-06T03:17:00.001+08:00

Sometimes I wish there's an algorithm for life.

What I've Learned From Wave

2010-03-05T22:39:00.001+08:00

24 hours after we first sat down to code in Sheares hall, I looked up and said: "I must blog about this."

"Ya, you should," Xialin said, and she looked up from her code for all of like 0.5634 seconds before looking back down at her computer screen. And I think that was the end of that conversation.

It could've been at 2 in the morning. Or 5am. Or maybe 7. Time kinda disappears when you've spent a whole night staring at monospaced fonts. I remember being hungry at around 2am. I also remember Biyan placing her head in her hands - I think I was plugging Haocong's backend into the UI then, and we both looked over at her and asked her if she was okay and she looked up and said she was thinking - but that might've been on Sunday night.

Like I said, I don't know. I can't remember. It's now all a big blur in my head.

What I do remember, however, is how much I've learnt from the Wave assignment.

What struck me the most about Wave was the sheer intensity with which Biyan and Haocong worked. I learned a lot from them. I can be very indisciplined - earlier on Saturday night I sat down to watch an animated video, putting off coding the UI, and Biyan said: "Cedric, I need to plug in my code into yours soon. So please work?" and I felt very guilty about that.

And even after I started work - and I didn't sleep like the other two - I knew that I did not match up to their level of focus. Sometime around 4 in the morning I did a count of Biyan's code and it was up to 1500 lines. Sure, there was a lot of whitespace, but my jaw dropped when I did the count, because I was quickly scrolling through the file and I figured out what she was writing and it was bloody complicated. The algorithm for check probably gave her the most trouble. And she was doing this on 2-3 hours of sleep.

Wave was also the first assignment in which I finally got to write code. As in - proper code - not the weak little descriptive languages like HTML and CSS with which I'd been playing since I was 15. Haocong said: "I need you to write this function, and you call this function from the back-end, and the parameters are this," and then he left me to do it. I really liked that. Here he was, an NOI programmer from his home country, and he trusted me to write stuff. I did it and I was quite pleased with myself after that. Learning a new programming language felt very satisfying; I'd only wished I'd done it sooner.

And there are other things, of course. Haocong spent a lot of time helping the two of us, because he finished his bit - the backend code - in about a night. I found that amazing. Haocong is probably the most understated elite programmer I've seen in 3216 so far - he doesn't say much, and he doesn't show off, but he gets things done. And then he tells you what he still needs done, instead of writing it himself, even though you probably know your code would take him all of 30 minutes to do. "When did you learn Javascript?" I asked him - and he said (without any trace of irony or inflection): "Last night."

(I think he took slightly longer to learn objective-C, but Mismatch currently has an iPhone version, and it looks great on his laptop. So I must say that, overall, it was a real learning experience working on this Wave app with him.)

Two more things.

First: our team made the mistake of waterfalling our software. I believe I've learnt my lesson - I won't do that again. Ever. Halfway through - at around 4 or 5 or 6 in the morning, I looked up from my code and said, thoughtfully: "You know what we should've done? We should've sat down together and written a whole list of interfaces before we started." And I remember Haocong sighing to that.

In the end, however, our app managed to work when we plugged things into each other the night of the deadline - but just barely. I thank God that we were writing a webapp, and not something bigger or more complex. And that became very true! Things began to be really scary when it hit 11pm and we were still nowhere near a playable chess game. Never again, I tell myself; never again.

Second: I no longer find myself insecure about my programming abilities. That is not to say that I'm great at it. I started real programming last semester, which was really late, and I found - to my surprise - how much I really enjoyed writing code. It was like finding a long lost friend. But because I was new to the school then, and new to so many things in Singapore, that I became scared and defensive when I saw all these great programmers in 1101 speaking in Java like it was their second language. They were better than me and they knew it. They didn't hesitate to talk over my head to show off how good they were with their code, and they compared lab marks with each other, and they asked me how much I got for my exams and my tutorials, sizing me up as potential competition and then then reconsidering that when they learnt I was new to this. And this made me really insecure - as silly as that may sound.

Today, however, I now know that these kids - while good - are nowhere near the level of Haocong or Biyan or Hung or Adhiraj. And that's a comforting thought. It means that I don't have to worry about those kids, for they are an order of a magnitude below than the 3216 programmers ... who are, in turn, an order of a magnitude below than the best programmers in the world. And I think that's important to know. What this means is that I needn't compare myself to them - because I know I'm new to this and I now know there's always somebody who's better than me. I have learned that what I really should be focusing on is the programming itself, because it's fun, and it's beautiful, and not the competition, or even the grades, because I shouldn't let all that taint the learning itself. And I think that is important.

Programming to me is fun and I hope to keep it that way. I'm glad I learned that from Wave. And so now: onward.

Holy Shit

2010-03-02T14:59:00.003+08:00

Y-Combinator's now looking for iPad startups:

Most people think the important thing about the iPad is its form factor: that it's fundamentally a tablet computer. We think Apple has bigger ambitions. We think the iPad is meant to be a Windows killer. Or more precisely, a Windows transcender. We think Apple foresees a future in which the iPad is the default way people do what they now do with computers (and some other new things).

This took me completely by surprise. While the iPad seems more and more like a computer ordinary people would choose over the desktop/laptop, it is - to me - complete unprecedented that Y-Combinator would be so forward-thinking as to demand a startup built around the iPad. And the coolest bit about this is that they're pretty much putting their money where their mouths are. I am floored, Paul Graham. Floored.

Marketing To Crack Whores With Kids

2010-02-23T17:37:00.002+08:00

Chewy Chong's presentation last night, titled "You, Others and the Business of People." was a tour de force. It wasn't particularly cohesive, and I didn't really get what underlying message he was trying to leave us with - but it didn't matter. There were too many valuable ideas in his presentation to ignore. And I think the bit where he talked about making us think - well I stopped and smiled at that. I really, really did think during the presentation, and I've come to realize that I've missed that kind of thinking.

Chewy has thrown at us quite a number of valuable ideas. To make sense of them, I'm going to deal with the ideas in (more or less) chronological order.

Play to your strengths.
I first heard of this a year ago, when I was over at my grandparent's place and Oprah was on. This man came on stage to talk about how 'fixing flaws' and 'focusing on weaknesses' were the wrong ways to go about doing things. I'm not sure if there's an upper limit to the idea. In principle, at least, this makes sense: I feel impotent in my math classes, and empowered in CS3216, and I suppose this is because CS3216 is my kind of thing and math isn't. But does that mean, then, that I should give up on my math altogether? What if - like many other people I know - it just means that I am lazy, and that I am not willing to put in the kind of effort that math requires? Does that mean that I shouldn't choose to do Computer Science (which I, well, think is cool) and do IS/e-commerce instead?

People are not like you.
Laurence recently posted a link in his blog about a funny phenomenon where people, googling the term 'Facebook login', ended up at a blog about the Facebook login.

There seems to be increasing anecdotal evidence that people use Google as a kind of natural-language command-line interface. We geeks cannot imagine this, of course, but Google must be to these people some kind of tourist guide or god, one who would take them around a virtual world they do not understand. People do not think like you and me. We know this, on some level, but I don't think it ever hits us hard.

Many geeks are now flaming the iPad. They do not understand that Apple is not thinking about them. The iPad is a computing device made for my grandmother, my aunt, my technophobic sister. It is not made for geeks.

It is understandable that the geeks are not happy with this arrangement.

I must point out that there is one scenario where the principle of 'people are not like me' fails. If you are looking for an interesting problem to solve, for instance, it would be far more efficient to solve a problem that you have already have (as opposed to finding an hypothetical problem affecting someone else). Granted, the problem might be interesting but not marketable, or it might be that your solution to the problem is too unwieldy for the vast majority of people out there. But that is what iteration and user-testing is for.

I think I now understand why startup founders often endorse 'eating your own dogfood' and 'iterate fast and furious'. The first is true because you understand your problems best; the second is true because - as Chewy says - people are not like you.

There is value in CPA.
I never understood before this lecture what so many startups saw in online couponing systems. I believe I do so now.

Chewy's done a really good job presenting this as a challenging, interesting problem, with a pot of gold waiting at the end for whoever solves the icky thing. I've not given much thought to it, as he has, but there are some things about the problem that sound remarkably familiar. MacHeist, for instance, is a good example of a CPA marketing campaign. Is there something to their model? Or is it luck?

Regardless, if you'd like more thoughts on CPA, go to Shannon's blog, she's got some good thinking done on couponing systems in Singapore (and the like).

There is more money, currently in CPM.
Facebook is aiming for a portion of this advertising market. They believe that they can do what Google has failed to - attract big name, powerful brands who would pay hundreds of thousands of dollars for the digital equivalent of a glossy, full-paged ad.

Chewy is right in saying that CPA is an interesting, unsolved engineering problem. He has, however, neglected to mention that nobody has quite figured out how to make CPM work on the Internet. Facebook thinks they've got a solution - and maybe they do. But it would be interesting to imagine how one might go about attracting big name advertisers onto the platform. (And how about newspapers? Or sites outside the Facebook ecosystem. What solutions exist in that space, then?)

Is Bing worth it?
There is a signal to noise problem on the Internet. Bing believes it has a solution to this problem, and I wish them well. That said, I'd like to think about the implications of a machine doing information processing on behalf of a user.

First: is Bing a good idea? If we're talking about accuracy, Google has a five-year head start over Microsoft. It has also got better engineers (multiplied with less bureaucracy) working on the problem, piped in straight from Stanford. So it's unlikely that Bing's results would be as deep or as accurate as Google's are, at least not for the next couple of years.

Second, Bing's value proposition is to help users filter signal from noise. There are two ways to do this. The first way is to focus on the way information is presented. This means executing very strongly on design, and writing tools that convert information into visual representations of data. The second way is to make decisions on behalf of the user, in order to reduce the amount of information thrown at him or her.

The first option is something Google is not very good at (design). The second requires competing directly with Google's engineers.

The first option also hides from its users the fact that Bing isn't as accurate as compared to Google's searching algorithm. Humans, after all, absorb visuals better than they do text. And so, if Bing makes things very intuitive, it is likely to be more useful than even Google itself.

Which option is Bing currently doing?

But let's have some fun. Assuming that it takes the second option, Bing exists slightly higher up on the processing spectrum than Google, and this has its own set of problems. What problems might those be?

Well, how does Bing decide between two kinds of information? Bing's model implies that it would have to make certain decisions for its users, in order to abstract away some information that other search engines normally display.

So, say that Bing picks flights from a certain airline, for instance, over flights from another one, and users won't know because the raw information would be abstracted one level away from them. (This is a bad example, I know, but bear with me). What would this mean for Bing? What would this mean for Bing's users? I'm not too sure, myself, but I believe these are questions that we'll all have to think about. My current takeaway is that Bing would either have to be so incredibly useful that the users don't care, or that it would have to write really clever algorithms for 'information processing. But isn't that a conundrum: decision implies making one choice over another, and how would a machine know which information to choose?

[Quasi-related thought: what other solutions might there be, for this signal to noise problem?]

Conclusion
I enjoyed last night's lecture. There was this last bit at the end where everyone started talking about how Singaporeans aren't entrepreneurial enough, but I'm going to leave my thoughts on the issue for another day. Till then, there's the Wave assignment to worry over.

Signing out.

Notes on Get Help

2010-02-21T19:28:00.001+08:00

This is a case study for, err, credit. My thoughts:

The Idea
Is a help app necessary? I think the app's cute. That said, I also think that people already post shout-outs and help-me!s through their Facebook feeds, the same way that I would ask for help on Twitter when I'm stuck on a project (or pissed off at Vim). This makes sense, since Facebook's status messages are modeled around Twitter's short-message/wide-community format, and Twitter itself is a remarkably useful place to look for help.

Are badges the right kind of incentive in a help app? If you really think about it, what you're doing by implementing a badge/reward function is that you're replacing a moral incentive (the afterglow from altruism, in this particular case) with an inferior 'status' incentive (virtual rewards and badges and rankings within the app). I'm not sure if this presents itself as a problem to getting help within Get Help, but - generally speaking - incentives are a very tricky economic game to get right.

The Main Page
Options are too wordy. Users don't read options beyond the first two words; options should be shorter.

Remove details. There are too many options available to a person wanting to post a call for help. Most of these data fields are simply unnecessary. Tags are unneeded, deadlines can be incorporated into the main post-field, estimated time, location and description are all overkill to the simple post mechanism.

Inconsistent typography. Pet peeve of mine, but why are a) the fonts in grey, and b) the fonts italicized? From experience, a single web page should have no more than two fonts (one, in this case, since you are limited by Facebook - which has its own set of fonts).

The Overview Page
Remove red buttons. The buttons are too big. And too red. Get rid of them, or change them to something befitting of Facebook's design.

Referrals should be sticky If someone is referred to you, it would make sense to have these referrals stick to the top of the notifications area. I would also suggest some styling to differentiate a referral from a normal post.

Individual Help Pages
Remove 'wish her luck'. If a person wishes to wish someone else good luck, they can very well comment on the call to help. There is no need to code an extra features that does this for them.

Is overdesigned. Is adding a sidebar necessary? It is perfectly adequate to display the help requirement (with icon or whatnot) and comments, with a small display panel of the 'probables' and 'helpers'. There's too much going on on the page at the moment.

In Closing
I read Adhiraj's blog post on Get Help, and I must agree with him that it's really quite something to have your app ripped apart by 40+ students. What a, err, privilege! That's all for now, folks, back to work.

World Builders

2010-02-21T00:41:00.002+08:00

COM1 is a special place to me. There are couches to sleep on, tables to study at, printers that go mmmmhhh every few minutes or so and a vending machine with green tea - green tea! - by the entrance.

Two weeks ago, I looked up from my Algorithms textbook and saw a man and a woman posing in front of COM1. It was late in the evening: there were golden slats of light from the main entrance pooling onto the lobby carpet, where the building was deserted, save me. I stared at them. The man was wearing a black suit, resplendent in tie and leather shoes. The woman had on a wedding dress - a white lacy one, though I don't remember more than that. They were beautiful, standing together, with their backs to the building and the photographer hunched over in front of them, waving his arm, asking them to put their arms out Titanic style. He photographed them with the pale pink stone-front of COM1 rising up behind them.

I remember thinking to myself: COM1 must've meant something important to them. Maybe they met there, or they fell in love while working on some project together, or he found her by the printer one day and offered to help print her notes, stole her matric number (and therefore: email address) and used that to ask her out for dates (yes, I know, I have an overactive imagination). Or maybe they just thought it would be a good place to take their wedding photographs. But the truth of it is that COM1 isn't a particularly beautiful building - I want to believe there must've been some other reason they would want to be photographed in front of it, especially when you think about all the other buildings on campus that might've looked better in a photoshoot. I didn't dare to ask - I had to study; but maybe it did. Maybe it did.

I've been thinking a lot about the places we live in, recently. Much of this thinking I owe to Jonathan Harris's seminal essay, World Building In A Crazy World, which I read last year and have been wondering about ever since. Harris argues that we now live in two places: in the real world, with charming buildings like COM1, and the digital world. He believes that we have a digital crisis on our hands: that while more and more of us spend much time on the Internet, we have failed to create digital worlds of meaningful value. In simple terms, we have failed to create COM1s of the Internet - places where people come together to create memories, shared experiences (even marriage).

Our Digital Crisis
Our online tools today are not made to create shared meaning. Instead:

Most online experiences are made, like fast food, to be cheap, easy, and addictive: appealing to our hunger for connection but rarely serving up nourishment. Shrink-wrapped junk food experiences are handed to us for free by social media companies, and we swallow them up eagerly, like kids given buckets of candy with ads on all the wrappers.

The problem with this isn't that we have less meaningful things to do on the Internet. Harris is not worried about that, per se. The problem with this is that more and more of us would be living our lives in the digital world in the near future, and unlike the world we live in - the real world, with beautiful cities and charming campuses - the digital world is not as good a place to spend time in.

Our online tools do a great job at breadth (hundreds of friends, thousands of tweets), but a bad job at depth. We live increasingly superficial lives, reducing our relationships to caricatures and our personalities to billboards, as we speed along at 1,000 miles an hour.

We trade self-reflection for busyness, gorging ourselves on it and drowning in it, without recognizing the violence of that busyness, which we perpetrate against ourselves and at our peril.

For the last 100 years—from letters, to phones, to faxes, to emails, to chats, to texts, to tweets—communication has been getting shorter and faster, but we are approaching a terminal velocity.

I believe that Harris is right. Twitter and Facebook - the two largest, most popular social networks of our times, are good only at creating short, superficial conversations. Twitter is - in effect - a never-ending ecosystem of water cooler chatter; Facebook as a tool is great for networking - for finding old friends and stalking new ones - but very bad for any form of meaningful communication. By extension, it is difficult - possibly impossible - to seriously maintain real-world relationships through the two sites. There are too few tools on the Internet today that would allow people to foster or even maintain thoughtful, meaningful relationships with each other. Worse, as Harris has it, the web does seem like a "giant cocktail party, full of chatter, gossip, and he said, she said". The web is less social than the social-media companies would have us believe - rather, it is more 'garrulous', more vulgar. Much of our digital interactions are built around surface chatter, not meaningful nor deep digital conversation.

But then, an interesting question: why is this so? Why are the majority of our communication tools short and superficial? Why is - as Harris says - our websites good at breadth ("hundreds of friends; thousands of tweets") but not good at depth?

One possible reason, I think, is that it is far easier to communicate at a superficial level than it is at a deep level. There seems to be a trend towards small, short, meaningless communication at the moment, with Twitter being the rage and Google launching Buzz. Short things tend to be more viral on the Internet. By that same logic, longer, more thoughtful sites exist but are limited to a smaller numbers of people. The irony is that if we continue doing chatter, there would be a point where we realize that we have built nothing of value for ourselves. We would realize that all that 'connection' has been for nought; we are connected now, more than ever before, but our connections mean nothing to each other.

I doubt there is a shorter means of communication than the tweet, unless we start to make monosyllabic grunts at each other or communicate silently, brain to brain. Brief gestures of communication can be beautiful, but can also be shallow. So what will happen next? Will we stop at the tweet, or will we bounce back in the other direction, suddenly craving more depth? I’d bet on the latter.

But even if we start to crave more depth, we cannot run away to a more primitive time. The momentum of technological growth is too strong for us to prevent it from defining our future. Like it or not, our future world will largely be digital.

Instead of fleeing to the forest, we must find the humanity in the machine and learn to love it. If we decide the humanity does not yet exist there in the ways we expect, then we must create it.

Harris believes that such places like Facebook can be done better for human relationships. I have been part of only two websites with shared meaning, and I know of only four others. I pine for such places, because I know - first hand - how incredible they may be.

World Building
COM1 is special to me because it is a place where I go to study, to program, and to suffer with friends. It does not, itself, have meaning, but it is designed to bring people together, who then do meaningful things with each other. If a married couple comes back right before their wedding to take pictures in front of COM1, then surely something somewhere must be right with it.

Websites are also like buildings. The form and function of a website and the actions you may do while you are in it determines the kind of memories and feelings you associate with the place. Websites by themselves do not have meaning - they are too cold and too machine-like to be of any comfort to us; instead, it is what websites allow us to do (often with each other) that matters. When you think of Facebook, you associate with it the splintered, second-by-second nature of the site, where you are bombarded by updates from your social network. I am not saying that this is not valuable - there is often value in the bombardment. But the kind of things you do in websites determine how you feel about them, and it is likely you will feel about Facebook the same kinds of feelings you do when you put an ear to a hollow pipe to eavesdrop on your friends, singing next door.

If websites are like buildings, then it stands to reason that people must build them. Harris points out that the world builders of the real world are engineers and architects and town planners, and they are responsible for the cities we now live in. Build a park and people will spend their evenings there; build a town square and friends will tell each other to meet at the center of such places - a phenomenon as old as town squares themselves.

The digital world also needs its own set of world builders. We need builders to create places of meaning - digital equivalents of town squares and gardens and parks. We do not need another Twitter, or another Facebook (or even the new Google Buzz). Twitter and Facebook are big sites, and successful ones at that, but I want to believe that there is space for smaller, more meaningful, more personal sites, places where people can come together to call their own.

There is a human need for meaningful communication that I believe exists in all of us, and too little of our world builders are looking for solutions to this need. Perhaps this is a problem that is unsolvable, like Harris suggests (is the online world a possible substitute for the real-world lunch?) - but I am inclined to believe that this is a problem that not many people are willing to tackle. And this is a marvelous opportunity, especially when we are near the point of critical chatter; it also leads me to ask - how would you build such solutions? How would they look like? And - most importantly - what may they be?

Looking for solutions
When I was 15 I created an online forum for my friends called Undergroundsquare. It was run on a PHPBB board - an old, ugly, clunky piece of software that was susceptible to spam bots and porn threads and terrible user-designed themes, and we decided to use PHPBB because none of us knew any better. We loved it to bits. Undergroundsquare became for us a central, online gathering point, a discussion place away from the classroom and the school(s) we were from. We would post questions to it, tease each other on it, and organize gatherings and movie-outings through the board, and we did so, whenever we could.

UGS died a silent death a couple of months after the founding members - my friends and I - left high school.

Shortly after that happened, I started writing this blog called Novelr, with which I eventually joined a blogging network named 9rules. 9rules was a startup, run by three Americans, most of whom have now moved on to different things. I mention this because 9rules was another one of those rare sites that Harris would like to see created. It was a close-knit community, with shared purpose and deep conversation, and till this day I know I can reach out (on Twitter, ironically) to these people, to ask for their help on any blog/design/programming-related matter.

There are other sites, of course, with such levels of deep conversation/meaning, but they are all (or almost all) limited in scope. Paul Graham's Hacker News is one of them; Craigslist is another. Slightly different, but in the same vein of improving human communication is Ustream, which got created when two American soldiers found out that there was no good way they could broadcast live video to multiple family members at the same time.

What do these sites have in common? If we leave Ustream out (for their approach to this problem is rather novel, and quite successful) we might conclude that the common denominator across all these sites is the fact that they're all forums, of some variation or another.

But here's the sad bit: all these sites, great as they are, are built on custom software. Generic, ready-made forum software hasn't change one bit from the time I first created UGS. And the truth here is that ready-made forum software sucks - not just the software itself, but the format of the forum hasn't changed, and it's still this ugly, heavy bulletin-board format that should be brought out and shot in the head. There's no threading, too many forums, no karma - all the new developments in community software that have been implemented in these successful sites (9rules, for instance, allowed members to earn points, to be used as goodwill currency) - all these developments are inaccessible to the person who wants to create a forum for his friends. I am one such person - UGS right now serves as a central gathering point for my friends, who are spread out across the globe in various cities and universities, and who almost never return home. (In fact, when I redid UGS a year ago, I had to hunt around before deciding on a heavily-modified version of bbPress - me doing the modifications, of course.)

Not everyone is geeky enough to do this. And while world building may involve creating new communities, or creating new, meaningful sites where people may cluster around, part of it may also be creating the infrastructure for people to do it themselves. If I had software that would allow me to quickly - and easily! - create an undergroundsqare for my friends, by gum, I'd use that.

Treehouse
There is much to be said for creating places of shared meaning between groups of people. But what of one-to-one connections? Harris points out that of all our human needs, the ones that have to do with authenticity, self-reflection, depth of communication, and real relationship-building are especially poorly answered online. Harris builds things that tackle the authenticity problem, and forums (new kinds, that are probably far removed from the Bulletin Board format) are an answer to the depth-of-communications problem. But what of real-relationship-building? How would a solution to that look like?

I have shown you that the forum format is one that works when you're trying to build shared meaning between a group of individuals. But what if - instead of giving people the tools for creating community, you take those tools and optimize it for just two parties? Say, people who love each other, who feel terrible when they are away from each other? Couples in long distance relationships, for instance, or best friends separated by distance (where one fears drifting apart, to the point where both parties don't recognize each other), or children removed from their parents? How might such an app look like? How would it work?

Text would probably be a major part of the solution. This has to be a specific kind of text - not Twitter level, 140 character messages, but long, blog-level posts. Lovers, friends, parents need to be able to express complex thoughts, or at least tell each other about their respective days, and text is the simplest way of doing this.

The problem with text, however, is that not many people communicate well in it - primarily because writing is a skill that has to be learnt. More people communicate through pictures than they do through words, so simple image uploading would have to be part of the solution.

But that still isn't enough. If you are to maintain a real relationship, pictures - while nice - are too superficial on their own to do any good for the relationship. There has to be an easier alternative to text, where people can share their thoughts and their day with one another; and luckily enough we do have a solution to that: video. In particular: live video, or video messages, which has recently become possible with Ustream's and Justin.tv's free APIs.

We've implemented text in Treehouse, and while we intend to do pictures and video, we are now struggling with the notion of doing it for our final project.

Problems with Treehouse
Most of the people with whom we have talked to about Treehouse cannot see the value in such an app. I do not blame them - on bad days, I think about the idea and wonder if we've got it wrong. But there are a number of things that I'd like to think proves otherwise.

I know a friend who is in a long distance relationship. She leaves private drafts in her boyfriend's blog, posts that he opens and reads when he comes online. This is clunky, and can be done better.

I have another friend who uses Treehouse. She regularly checks on it now, because she and her boyfriend would take turns telling each other about their days. They post messages, and choose moods, and complain to me that they would like an email notification feature to tell them when, exactly, either one of them has updated their treehouse.

Yet another friend has a boyfriend who doesn't write much, and she has asked for pictures to be implemented as soon as possible. She thinks video posting is a wonderful idea, though she's in Australia at the moment, and so is constrained by bandwidth limits.

I have learned, however, that Treehouse is currently in a quagmire. If we are to do it as our final project, we must be fairly certain that we're on to something, and the only way to be sure we're on to something is to be compelling enough to attract plenty of new users. The problem with that is that Treehouse will only be compelling if we implement three things: 1) if we take it out of Facebook, 2) if we implement photos sharing, and 3) if we implement video messages. We are not 'over the hill', as one might call it, and therefore we have no way of knowing if what we think is true in theory would translate to real world usage. Regardless, Treehouse is our stab at the problem. We'll see how it turns out in the end.

Conclusion
I believe we can do communications better. Friends drifting apart after going overseas, lovers falling out of love in a distance relationship - these are problems that are as old as migration itself, and the solutions to these problems would be very, very valuable if and when they are found. I believe that these solutions, when they come, would not look radically different from what we have as communications (online) today. They would instead be smart repackagings of certain elements, tweaked and optimized for the problems they intend to solve. The makers of Wave, at least, have got one thing right: email just doesn't cut it any more. It is time to find better, deeper communication channels, ones that (hopefully) do not look like Wave.

I'd like to close with Harris's takeaway, which he says at the end of the fourth section of World Building In A Crazy World:

Speaking especially to young students of computer science, art, architecture, and design—I would encourage you, as you imagine what you want to become, to consider becoming digital world builders.

Help construct our future digital world. Build honestly, naturally, authentically, beautifully, not motivated by page views or ad revenue but by what the digital world should be, in its purest, noblest sense. Articulate digital spaces that nurture the soul and the spirit.

Don’t leave it to today’s companies to solve these problems, as they will only perpetuate the same habits they have already adopted. There needs to be a new vision for the future of the web, one that is sensitive both to the human individual and the human collective, just like real life.

(...) The rest of the human race—the struggling journalists, the embattled authors of books, the makers of music, the normal folks who have been robbed of their individuality by today’s web—should expect its digital world builders to build them beautiful, honest, nourishing worlds.

We need good world builders. Builders to build the COM1 equivalents of the Internet. As humans, yearning for connection, we deserve better sites, better buildings in our digital world. And it's also likely that the world builders of tomorrow would be as rich as the world builders of today. Zuckerberg has done good, but Facebook isn't particularly meaningful. So, you know - why not us?

Hush

2010-02-03T11:09:00.002+08:00

Judo friend of mine recently did a post on conflict:

"I think that's just plain normal for young adults to have conflicts. You people are young and energetic and so full of hope. You think the world revolves around you, your words should be heard, your stand made clear and you would fight sword with sword if you felt threatened. That's young adults," she said. I fell silent.

"But things will look different after you reach my age, when you start thinking of death. Well, I'm not trying to terrify you but that's just what you do when you're as old as me. Suddenly, all the conflicts and quarrels will look.... meaningless."

"Don't worry too much, things will get better. When the time comes, you will be happy that you've made a wise choice back then. And trust me, you will laugh at yourself when that time comes, for being so....like a young adult," she gave me a big smile after that.

I think this is exactly what I needed to hear. Thank you, Horng Eng. You made my day.

Flixster

2010-02-02T18:03:00.017+08:00

This post is for the Facebook Application Seminar, and it will be about Orry and co's app: Flixster.

A few things before I begin. First, I'm not going to talk about Flixster itself, because I think Orry's covered the app pretty comprehensively. I do find it interesting, however, that while it's called Flixster from within the application, Facebook calls it 'Movies' on the application status bar, on the bottom left of the screen. This suggests that if Flixster is the official Facebook movie application, then it may well be possible for other businesses to position their sites as official providers of various other niche services - like Food, for instance, or Music, or Job Listings, or even a Maps app from within Facebook itself.

What I really want to talk about is Flixter's move into Facebook. Why did they do it? Flixter has already built a strong community around its services, and so why did it approach this growing network - this 'gated community', with its site and service? What exactly are the benefits that Flixter sees in Facebook, and what might that mean for the rest of the web?

I ask this because there are a conspicuous number of other web applications that are not integrated into Facebook. Google, for instance, is unlikely to integrate anything of theirs into Facebook's ecosystem, for a number of reasons that I'm not sure are merely competitive in nature. There are also a large number of indie developers who would never consider plugging their apps into Facebook - 37signals, for one, and Wufoo; and I'm fairly certain that Facebook does want developers like these to plug their services into the site. (I also get the impression that Facebook wants to be the 'operating system' of the web, in the sense that it wants to be a platform for just about anything people-related that you want to do.) So again, why Facebook, and what exactly should you take into consideration, before bringing an app into the Facebook ecosystem?

Let's look at Flixster first, because it comes from an interesting position. I particularly liked Orry's point of how, if Facebook dies, Flixster would still continue to exist. And indeed the benefits to Flixster for plugging into Facebook's ecosystem is fairly easy to guess: you get a low-barrier-to-entry in a captive audience, which means that users won't have to go through an extended sign-up process on Flixster's parent site, and you get to leverage Flixster's (existing) viral nature onto Facebook's far larger audience. The same principles that applied to the Flixster network must've been easy to implement within Facebook, and on the surface at least, both services seem to be a good fit for each other.

That being said, though, there are a couple of questions that I'd like answered, questions that matter to me as a potential app writer. It seems to me that developers today have two options: to build for Facebook, or to build for the open web (and it is ironic that it seems as if there are two 'internets'). I must note, however, that the benefits available to Flixster are benefits that are applicable to almost all other apps within the Facebook ecosystem - a low-login-barrier-to-entry; a high density of potential users, and a set of tools designed from the ground up to be potentially viral for users. So what do they give up, in exchange for all these benefits?

They give up the right to define their brand, for one. This isn't particularly dangerous, because companies making these apps still have the ability to link to external sites related to the app itself. But Facebook's brand is pervasive, and if the app's popularity outstrips that of the original site, there is a real risk that it would be defined by the first point-of-contact, which for many users would be from within Facebook itself.

If you don't believe me, consider: would you have heard of Oodle had it not been for Facebook's Marketplace? And now that you have, is not your experience tainted by the first point-of-contact from within Facebook? Let's take it a step further: let's say that Marketplace is a far lousier experience than the parent Oodle.com site. Would your impressions of the brand be affected by the first, lousier, app? It probably would now, wouldn't it?

But what else is there that might be affected? One thing I think you lose is the ability to choose the kind of community you build around your app. A peculiar truth of the Internet is that an online community is always defined by the 'tone' of the site that spawns it. The simplest way to see this in action is to observe the kind of comments you get on blogs and forums: if a blog is bimbotic and snarky, the comments on said blog are likely to be as bimbotic and snarky as the blogger herself; if the blog is thoughtful, the comments are likely to be longer and more considered than is the mean.

That is not to say that Facebook spawns users that are dumb (though Youtube, as a comparison, probably has one of the dumbest communities on the whole Internet) - rather, Facebook contains users of a particular kind. Facebook users are attuned to the vocabulary of the site: they are used to short, superficial posts, distracting little games, and plenty of profile-hopping and/or the clicking of random links sent by friends and family.

As an external developer, your app would be defined by this existing, attention-deficit community, and you'd probably lose your ability to set the tone of your site/app. This is important to consider: Flickr would have been a very different app had it launched in Facebook, the same way Facebook would have been a very different app had it launched in Flickr.

I'd like to close by saying that while Flixter may have found a wonderful match in Facebook, I am starting to wonder if it's worth it to build Treehouse within Facebook itself. Treehouse is constructed around three ideas: sharing, meaningful communication, and privacy, of which only one (sharing) is a match with Facebook's underlying philosophy. Would it be worth it to sacrifice brand and community for users? I'm not sure, but I'm willing to bet I'll find out, and soon enough.

N.B.: This may not apply to games, but just as a test - go to Kongregate and observe the vocabulary of the community clustered around the site. How different are they from Facebook, and which do you think is better?

CS3216 In The News

2010-02-02T02:30:00.004+08:00

My Chinese is terrible, but. Oh. My. God.
Also, on Causes:

On Treehouse

2010-01-29T06:31:00.009+08:00

It's 5am here, really late, and I'm slightly woozy in the head. I must say, though: I'm feeling rather pleased with what we've accomplished in just two weeks. Got a few things to scribble down before I turn in.

What I've Learned on Teamwork
I found this very surprising, but the last few hours of work on Treehouse turned out to be some of the most relaxing we've ever had. We decided not to write new code. Things had picked up over the last week, and it began to seem fun, real fun. Adhi got his computer up and running again (he's now on Linux, bless his soul); Kah Hong had less to do (and became, almost instantly, a much happier man for it); I got better at churning design and stylesheets and wrapping things around whatever the programmers handed to me. And we didn't have to worry about the paperwork, since Andy did most of that.

It was a pretty good ending to the first assignment.

I think what's most surprising about this was that we had a really high rate of depression, given our technical ability. Adhi got depressed first, because he felt like he wasn't contributing to the team. Then I got depressed, because I was trying to hold the team together and it felt like I was loosing it. And then Kah Hong got really mad at me (and yes, if you're wondering, it was my fault) just as we were pushing a really buggy version of the app.

And then things became better. Kah Hong squashed a whole village of bugs on Wednesday night, and I did this gorgeous page for the app, and Adhi added a couple dozen new features in one afternoon. Without much discussion, we had collectively decided to stop development on the photos and videos section of Treehouse. We got together and began to polish - really polish - whatever we had. I think (hope?) the results show, despite the small number of bugs and design quirks still left in the app.

On Productivity
I've found that collaborating on gTalk to be the best way to work on Treehouse. This was another thing I found surprising. The guys at 37signals were right: alone time is the best development time, and it shows in your work when you've got nobody there, physically, to disturb you as you're programming. We spent the vast majority of week 2 physically separated from each other, programming together online, passing files through Dropbox, and checking with each other only occasionally through the odd chat convo. We got a lot of things done that way. I found that remarkably cool.

So what have we built?
I think it's about time that I explained the ideas behind Treehouse. There's a shiny new icon in my sidebar, pointing to a TLD listing the general principles we've built towards, but I want to explain some of the things we see in the app, too.

For the heck of it, I'm going to do this in the format of a Y-Combinator application. I'm also going to be tongue-in-cheek about this, and maybe (just maybe) I might send this in, for fun, as part of their summer incubation program.

What is your company going to make?
Treehouse attempts to solve the Long Distance Relationship problem. It allows users both on Facebook and off to create private forums/blogs (to be called 'treehouses') with each other, which then allows them to share text, moods, pictures and video messages.

Possible use scenarios include couples in LDRs, and parents with kids overseas. Both relationships require lots of information-sharing to have the relationship survive the distance, and this is difficult to do given equally capable but less specialized (or disparate) tools.

There are lots of interesting possible features. One such feature is to use Justin.tv's newly released API to enable user recording/broadcasting from within the browser. Another is future posting - if a person is busy and cannot come online for the next couple of days, say, he or she may record a series of audio/video messages and set them to post once a day for the entire duration he/she is away from a connection. And then there's building an iPhone app - we've already got mood data in Treehouse, we can leverage that to show one party how the other is feeling through a graphical interface on his or her iPhone.

For each founder, please list: YC username; name; age; year, school, degree, and subject for each degree; ~~email address~~; personal url (if any); and ~~present employer and title (if any)~~. Put unfinished degrees in parens. List the main contact first. Separate founders with blank lines. Put an asterisk before the name of anyone not able to move to Boston for the summer.
taykahhong Tay Kah Hong 2008 (NUS Bachelor of Computing in Communications and Media) www.taykahong.com
shadowsun7 Cedric Chin 2009 (NUS Bachelor of Computing) www.isnerdreturntrue.blogspot.com
Adhiraj Somani 2009 (NUS Bachelor of Computing (Honours) in Computer Science)
Andy Hoang 2008 (NUS Bachelor of Business in (iamnotparticularlysure))

Please tell us in one or two sentences something about each founder that shows a high level of ability.
I built Novelr, lent a hand in starting Web Fiction Guide, and am currently working on a digital publishing house, Pandamian. Kah Hong is in a startup, called sgBEAT, with his brothers. Adhi is an International Olympiad in Informatics silver medalist. Andy is just plain awesome.

What's new about what you're doing?
Nobody's actually thought of tackling this problem. We've got blogs to connect one person to many (one-to-many); we've also got forums to connect many people (many-to-many). Nobody has really quite figured out how to provide meaningful ways for individuals in distance relationships - be it parents worried for their university-going kids, or LDR couples - to communicate and share their lives with each other.

What do you understand about your business that other companies in it just don't get?
They've not thought of it yet. Maybe it's a market nobody's interested in, or maybe it's just something hackers don't find challenging enough. I don't know, but I'm using Treehouse alpha now and it doesn't feel that way to me. It feels useful.

What are people forced to do now because what you plan to make doesn't exist yet?
They email each other. They skype. They create private blogs for the family to follow their exploits. There are problems with all of these.

Email is messy; it has no standard html across clients and it's rather clunky for images and videos. Plus there's no easy way to archive conversations (as in separation of personal, meaningful emails from non-meaningful emails). Plus the design for emails mostly suck.

Skype rocks. We do not intend to replace Skype, but we're aiming for that sweet spot just below Skype, where time zones become a problem. Treehouse would be a good alternative to push messages - be it text, or pictures; audio or visual - when you just can't stay up late.

Private blogs make a lot of sense. But we think there's a market for making something simple enough for parents to understand, and tailored enough for couples to use without going to other sites/tools. Execution on design is particularly important - the site must be good to look at.

How will you make money?
Two ideas. One, charge for bandwidth (photos + video, much like how Flickr does it). Second, partner with speciality handcraft marketplaces like Etsy, for a cut of the sales (maybe 2%-4%). Users may then have gifts delivered to their loved ones, from within their treehouses.

Who are your competitors, and who might become competitors? Who do you fear most?
Google Wave is similar in concept, but they currently get the UI very wrong, and as a service is too fiddly for normal people. This may change, though, as the new team comes in (some of them from Etherpad). There're also the existing blog services - Tumblr, in particular.

For founders who are hackers: what cool things have you built? (Include urls if possible.)
I customized Undergroundsquare for my friends, though I didn't build the underlying software. Kah Hong did some of sgBEAT.

How long have the founders known one another and how did you meet?
We met at this crazy module in NUS called CS3216. There's a story in there, I tell you.

What tools will you use to build your product?
PHP & MySQL, Justin.tv's API, Actionscript, probably Amazon EC2 and S3 for storage.

If you've already started working on it, how long have you been working and how many lines of code (if applicable) have you written?
I believe we finished iteration 2 at midnight last night.

If you have an online demo, what's the url?
http://upthetreehouse.com/

How long will it take before you have a prototype? A beta? A version you can charge for?
We'll probably have a solid beta up by the end of the module, if I can find a team of good programmers to back me up.

Which companies would be most likely to buy you?
Facebook, probably. But Facebook's platform is built on connection, not meaningful communication, and there's this culture of short, superficial conversation on it. Google would be another - they bought Blogger for similar reasons.

But if we're being honest - nobody worth knowing. We're in Singapore, and the acquisition model isn't exactly one that's feasible in the current (tech) startup climate.

If one wanted to buy you three months in, what's the lowest offer you'd take?
I've got this prof, and he set us a minimum of 250 million for an A. I'm kidding. It depends on the amount of work and the offer, though it'll probably be hard to walk away from a million USD.

Why would your project be hard for someone else to duplicate?
This is a problem. It wouldn't. It's not technically challenging, so the best hope we've got is to iterate quickly, listen very attentively to users, and build a strong community around that. A strong community is a significant buffer against competition, all things being equal.

Do you have any ideas you consider patentable?
No.

What might go wrong? (This is a test of imagination, not confidence.)
Google might finally figure out how to make Wave intuitive. The service is currently a solution in search of a problem, and my fear is that they'll realize this to be the one (major) problem they may actually make a dent in, given their capabilities.

Also, there's always Facebook itself to contend with, who may see the interesting work we're doing and set its engineers to build something similar into the network itself.

If you're already incorporated, when were you? Who are the shareholders and what percent does each own? If you've had funding, how much, at what valuation(s)?
Wow, incorporation. That sounds cool.

If you're not incorporated yet, please list the percent of the company you plan to give each founder, and anyone else you plan to give stock to. (This question is as much for you as us.)
25% split each way, though we might want to give some percentage to the prof. (This is a tricky issue, needs discussion)

If you'll have any major expenses beyond the living costs of your founders, bandwidth, and servers, what will they be?
None.

If by August your startup seems to have a significant (say 20%) chance of making you rich, which of the founders would commit to working on it full-time for the next several years?
None. I'm bonded to the Singaporean government, Adhi wants to get a compsci degree, Kah Hong hopes to get good grades for a backup, in case starting up fails. Andy I'm not sure.

Do any founders have other commitments between June and August 2007 inclusive?
Gee, we have class. First sem of the new academic year.

Do any founders have commitments in the future (e.g. have been accepted to grad school), and if so what?
We're, err, undergraduates.

Are any of the founders covered by noncompetes or intellectual property agreements that overlap with your project? Will any be working as employees or consultants for anyone else?
None. We're exempted from the normal NUS IP policy in CS3216.

Was any of your code written by someone who is not one of your founders? If so, how can you safely use it? (Open source is ok of course.)
No.

If you had any other ideas you considered applying with, feel free to list them. One may be something we've been waiting for.
May we write an app to save the world?

Please tell us something surprising or amusing that one of you has discovered. (The answer need not be related to your project.)
Vietnamese is a wonderful cryptographic tool. (That's an inside joke, for those not in the know).

Everything So Far

2010-01-27T15:01:00.004+08:00

I did a post not too long ago, to be honest, on why our app would be limited to two users per instance, but I pulled it because I'm not sure if it was the right thing to do. We had an internal argument about it. Quite a number of things have happened since I last blogged - the least of which being the problems we've faced in building Treehouse. But I'll get to that in a bit. There are a number of things I'd first like to talk about.

First: the app. Treehouse is this thing we're working on that attempts to solve the 'Long Distance Relationship' problem. We were in the Arts canteen, it was two weeks ago, and we were getting nowhere with our ideas. And then Andy came along and pitched us three of his.

The first idea was interesting, but not particularly cool (I can't remember exactly what it was, but I suspect that it was the complaining website idea that he first brought up in Show and Tell).

The second idea was the one that became Treehouse. Andy had a girlfriend in America, and they were in a long distance relationship. It was hard on him. We understood that. It was an interesting problem nobody had really thought through, and I remember thinking that if we had problems like this, it was likely someone else would, too. We also realized that distance relationships weren't just limited to girlfriends - Adhi and I had parents back in our respective home countries, for instance, and we figured that this arrangement had more or less the same difficulties as Andy's - meaning: we're separated by distance, and these are loved ones we're leaving behind. And so we thought this would be a good problem to try and solve. (Actually, I thought so; Kah Hong liked it; and Adhi needed a lot of convincing. Adhi needs a lot of convincing for almost everything, but this in particular he needed an hour on gTalk).

And so this was how we started doing the app. Almost immediately things started going wrong. Adhi's computer broke down. Kah Hong found that he couldn't use Code Igniter in Facebook, and then we argued over a name for three whole days, which was rather grating for all of us. We kept getting held back. Sometimes it would seem like we were all set on doing things this way, and then one of us (who this person was would change from time to time) would stop the process, asking for more time to think it over. And soon I began to realize that we were experiencing some form of analysis paralysis, where every feature would be called into question and dissected and argued for, and every bloody decision the coders wanted to make (which in the first iteration was Kah Hong and I) was second guessed. It felt like working in a bureaucracy - like working in Microsoft, even - which was strange considering it was just four people in a team. And that got tiring really fast.

It came to such a point where I grew incredibly stressed over the app. There was one night, at about 2 in the morning, where I felt like there was this huge weight on my chest and I couldn't sleep. This is rare. The only other time I felt like this was when I was in Form 6, and I had founded a debate club, I was playing Judo at Nationals and I had the school newsletter and two online communities to build and manage. And now the feeling was back - for just one app. One awesome idea of an app, but one app nevertheless. I opened gTalk and began chatting with the Novelr people whom I had worked with in the past - these programmers and writers who have had work experience doing things in small teams, and they talked me out of my frustration. (Quote of the day: 'Team dynamics is a tricky thing. You just need forgiveness. Lots of it.' - this was coming from a programmer, a really good one at that, and it cheered me up considerably)

So what have I learned? I've learned that the software engineering counts for very little when you've got team dynamics to worry about. It turns out that I was both right and wrong about the separation of code - I didn't touch the PHP that Kah Hong and Adhi wrote, but I do a lot of CSS and styling and this is one form of coding, in the sense that things can still go very wrong when we push to the server.

I've also learnt that I cannot work with everyone, and this is humbling, to me, because I used to pride myself in my ability to mesh with all kinds of people. I still like the people in my team, but I think that there may be instances where good individual personalities come together and it just doesn't work out. I'm not sure why this happens. I suspect normal working relationships are put to the test - or left to burn - when teams are asked to deliver an awesome app in two weeks. I am grateful for this lesson. Better here than outside, in the working world. And I believe that I'll come out of this a stronger person, the same way I came out of Form 6/Judo/Debate/Novelr/9rules a stronger person.

So what have we left to do? We've been building the app to allow multiple people into each treehouse, and while my teammates have argued that it's wrong to limit Treehouse to just two parties, inside I'm not so sure. My intuition is telling me that there's something in building a two-party publishing/sharing platform, since most platforms out there currently cater to one-to-many (blogs) or many-to-many (forum) communications. And part of the reason we're building Treehouse the way it is is because we believe Facebook to be particularly bad at creating meaningful conversation. We think that it's really good at connecting people, but that most of the interaction between people within the site are superficial, short messages, and all that isn't particularly useful to a parent, say, or a boyfriend, or a husband working overseas.

So I'm not sure about the multi-user treehouse thing. I believe there's something to two-party communications, something that email isn't a solution to, but I'm not sure what. The LDR thing is certainly one such problem. And the interesting thing is that there may be others, because we're living in an increasingly borderless world (which can only mean new problems in human connection). But then again we've got a lot of work to do, so I guess I'll stop here; I'll probably come back to the idea in a couple of months.

Scrum!

2010-01-19T00:13:00.008+08:00

I loved the bit in today's lecture about Scrum. Then I came online, and googled it, and found this on Wikipedia:

Poor people, hah! Hilarious! If there's anything ironic in this, though, it's that unlike Wave, Scrum can actually be understood.

On Execution

2010-01-18T14:30:00.002+08:00

Derek Sivers, failed musician, programmer and entrepreneur, recently sold CD Baby for $22 million. He has this to say about ideas:

It's so funny when I hear people being so protective of ideas. (People who want me to sign an nda to tell me the simplest idea.)

To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.

Explanation:

* Awful idea = -1
* Weak idea = 1
* So-so idea = 5
* Good idea = 10
* Great idea = 15
* Brilliant idea = 20

* No execution = $1
* Weak execution = $1000
* So-so execution = $10,000
* Good execution = $100,000
* Great execution = $1,000,000
* Brilliant execution = $10,000,000

To make a business, you need to multiply the two.

The most brilliant idea, with no execution, is worth $20. The most brilliant idea takes great execution to be worth $20,000,000.

That's why I don't want to hear people's ideas. I'm not interested until I see their execution.

So here's the trick question: which side, of the above equation, do you think competitions like Startup@Singapore fall on? How many S@S winners have actually gone out and executed their brilliant idea? And, most importantly, why are business plans so important to the startup establishment here when it's people + talent + execution that matters?

Designing Within Facebook

2010-01-18T14:19:00.002+08:00

Week one of app-building, and we've already come up against the constraints of building within Facebook. Exhibit A: design. How does design work within Facebook, if you're not building a flash-based app? The site already has a compelling visual identity, with 10 point sans-serif fonts and a dark blue theme, and so how are you going to a) feel 'natural' - i.e. part of the Facebook ecosystem, and yet b) not feel like you're some core part of Facebook itself?

Add that to the other limitations you'll have to consider. For instance, the maximum width for a Facebook app is 760px. What can you do within those pixels? How far down should the user scroll, and how high should the app be, if it's written in FBML? Is an iframe a better option, usability wise?

And there's speed: Facebook is notoriously fast. People surfing within Facebook expect your app to match those loading speeds (though they make exceptions for Flash apps, I suppose, because everyone knows Flash takes time to load). If you can't match Facebook's speeds, what can you do to convince people to wait just a wee bit longer for your app to load? Should you use an animated background to leverage user perception of Flash? Do you use a complete different design scheme to convince users that this isn't Facebook, and you're allowed to be slightly slower?

Also: UI elements. There's a bank of ads on the right side of the screen, how are you to design around that? You want users to focus on what you have inside the app. Do you use different fonts from the ones displayed in the ads? Do you use customized buttons in your UI, or use Facebook's own? Plus weightage - site design has to have some form of aesthetic balance. WIth a bank of ads 'weighing' down one side of the screen, how do you balance the other side out? Use bigger geometric shapes? Colour?

Most importantly, however, how can I convince users that what they're dealing with is a 'private' app, within the open platform that is Facebook?

Boy do I have my work cut out for me.

To The Non-Geeks

2010-01-14T18:14:00.003+08:00

Earlier this afternoon Kah Hong, Andy and I were sitting down at the Biz canteen to work out some ideas for our Facebook app assignment. Adhi was away at Science, and so while we waited for him we started talking, dicking around a little, joking about pie-in-the-sky app ideas. Something struck me almost immediately. As Kah Hong and I went about discussing possible improvements for CORS and our app (and the rough technical implementations thereof), Andy cut in at various points to ask us to clarify things as we went along. This took me by surprise. He had no idea how and what we were going to do, apart from sitting in front of a computer screen and typing erratically. I had forgotten that to a pure business student (or a pure arts student, or a pure science student, etc), the process of creating software seems like a magical, imaginary thing. It was not too long ago, after all, that it seemed like that to me; at any rate I've yet to fully experience a complete development cycle - all the way from idea to spec to completion. And yet, if Andy is to help manage us, he would have to gain some basic understanding of how a software development team worked. I told him to read Joel on Software, and then I decided to write this post (in the spirit of documenting everything I learn in this module - heaven help me in that task).

The thing is this: I may not be a particularly experienced programmer, but I do know a few things that may come in handy for a manager new to programming in general. I do not know yet how we are to work together, but first on a list of things they must know about techies is, of course, programmer mentality. Here's an open letter to the non-geeks; the non-tech people in CS3216. It's about how the programmers think and how they work in your team, and it's very general, and slightly noobish, but I hope it does some good:

To the Non-Geeks in CS3216,
Greetings from geekland. We are the programmers you may work with, and you will probably find us slightly odd. Here are some things you should know in order to help you manage us more efficiently.

1. We write code. You probably already know this, but programming is the act of typing a very strange language into a computer. If you look over the shoulder of a working programmer, you are likely to find utter gibberish. Think of this utter gibberish as instructions in a language that you do not know, like Chinese, say, or Latin, or Greek. What we are doing when we program is that we are building different components of a final product. At the risk of sounding too idiotic, think of it as building a plane. First we lay down the skeleton, and then we lay down the engines, and then we put in the couches and shiny exteriors and paint.

2. Programming consists of three main stages. The first stage is planning. You know a programmer is planning when he stares out the window and doodles on a paper with a pen. Just as an engineer has to figure out what kind of engine to fit into a plane, a programmer has to figure out the best solution to a problem. An example of one such problem: programmers usually have to trade between time and space. Code that runs fast usually takes up a lot of space. On the other hand, code that saves space runs slow. A programmer's job is to find a balance between the two. This is but one simple example of the kinds of things programmers have to think about when designing their code; I won't go into detail, but they are really no different from a builder or engineer who has to choose from a set of varying materials.

The second stage of writing code is writing code. This is the easy part.

The third stage is called debugging. Debugging is the process by which programmers remove errors from software. Because programmers cannot see what they are building, they may sometimes connect the wires from one engine to the fuel tank (or someplace else) and so cause their plane to explode. Debugging takes a long time, because different parts of the plane that were built at different times may interfere with one another. Programmers don't usually know where things go wrong, or what causes things to go wrong, and so they would have to look carefully in their various interlocking plane parts to find possible errors.

3. Reading old code takes longer and is harder to do than writing new code. This is one reason debugging takes longer. Keep that in mind while planning programming milestones.

4. We speak gibberish. We may sometimes sound as if we are speaking goobledegook. We tend to talk quickly, and wave our hands about, and not make sense. This is normal. Please forgive us for this. Have patience, and understand that there are really only three main stages of programming, and a few interlocking parts in any software development project. Ask your programmers how many portions are completed, and which stage they are at for each portion (thinking or writing code; debugging happens later, usually, unless your programmers are reiterating their code - but nevermind about that).

5. Eep feature creep! Programmers love to write cool things. Sometimes we try to add too many cool things, and fail to produce a good end-product. This is where you come in. Look at the feature list. Arrange them in order of priority. Get rid of all the features that the app may do without, especially so when us technical people are approaching a deadline. Good design is not when there is nothing extra to add; it is when there is nothing left to take away (and still the product is able to solve the problem it set out to solve). Force us to do that. We would thank you for it.

6. Read Joel On Software. We are noobs (or at least, I am). He isn't. We're probably going to program in a slightly slapdash manner, especially so in this module, but Joel knows his stuff. He's been doing it for years. So read him. He should do you some good, if you're ever required to manage a bunch of programmers again in the near future.

Yours,
The citizens of Geekdom.

PS: Andy, guys, anything else to add?

Thoughts On Teams

2010-01-14T03:38:00.015+08:00

I've been giving some thought to the icky issue of building teams, lately. We've been told from the start that the ideal mix of people would be a certain combination of programmer, designer, and marketer; and I've a feeling we all have an idea of how teams should look like and work, from our past projects in NUS and high school and so on so forth.

But then as we begin to form our teams an interesting series of questions begin to come into play. What is the ideal ratio of technical people to non-technical people? Who - or what kind of person - should lead the group? Are non-programmers expected to touch code? Is it possible to divide teams into designers vs programmers (interesting if we consider that web programming isn't exactly MVC). And the big one: which of the two is more beneficial? To find people you can get along with, or to find people with good technical ability?

These questions (and how we approach them) are probably what our seniors meant when they talked about CS3216's emphasis on the 'soft skills set' of software development. I also suppose that what we learn from trying to get our teams to work together are lessons that we'll carry with us for the rest of our lives, out to the working world, even, especially so if we're required to work in small teams.

Are there answers? Well the good news is that we're not the only ones who've had to answer such difficult questions. In fact, a large portion of these answers are available online, on blogs by people who've taken the time to document the process of running small, web-based startups. Here are some of the ideas that I'm interested in testing:

Who Gets To Touch Code?
One of the first things we did when we formed our team was to figure out who would do what and why. Adhiraj and I sat down, and we quickly came to an agreement that I would not be allowed to touch code. Brook's law says that "adding manpower to a late software project makes it later", and an interesting corollary of this law is that the speed of a software project usually depends on the speed of its slowest programmer. Being particularly new to programming, I passed my PHP book to Adhi, and so decided to do front-end design.

Brook did not make this rule up. And while the corollary is my take on the law, I believe that it does make sense: a new programmer is significantly slower than a more experienced one, and so would take longer to complete tasks set out for him, thus pushing back debugging, and testing, and so on so forth. And if we consider the fact that a newer programmer makes more mistakes and creates more bugs than a good one; and we add that to the curious reality that is debugging (which takes far longer than writing new code) - then we should come to the conclusion that it's actually better off to have a smaller, skilled programming team.

(Okay, Adhi's told me to cross this out, since it's not exactly correct. We're not sure how we're approaching the code, and we're not sure how the jobs are going to hold when the deadline approaches. Will tell you how it goes when we've finally started programming.)

A 37signals Take
37signals is a Chicago based startup that's been building webapps for the past 5 years. In their book, Getting Real, they talk about using teams of three for version 1.0 of any new webapp.

For the first version of your app, start with only three people. That's the magic number that will give you enough manpower yet allow you to stay streamlined and agile. Start with a developer, a designer, and a sweeper (someone who can roam between both worlds).

So that's another idea. Get a programmer, a designer, and a person who's sort of a jack of both trades. Perhaps more realistically, get two programmers, because it's likely that the programmers we have in CS3216 may still need to pick up the necessary technologies in order to code the app. Adhi is one, Kah Hong is another; I'm working as sweeper. Let's see how this experiment works out.

The Support Layer
The idea of a Developer Abstraction Layer comes from Joel Spolsky. He argues that software companies should be built around programmers, and everyone else working to make sure that the programmers are able to do their job.

Think of your development abstraction layer as a big, beautiful yacht with insanely powerful motors. It's impeccably maintained. Gourmet meals are served like clockwork. The staterooms have twice-daily maid service. The navigation maps are always up to date. The GPS and the radar always work and if they break there's a spare below deck. Standing on the bridge, you have programmers who really only think about speed, direction, and whether to have Tuna or Salmon for lunch. Meanwhile a large team of professionals in starched white uniforms tiptoes around quietly below deck, keeping everything running, filling the gas tanks, scraping off barnacles, ironing the napkins for lunch. The support staff knows what to do but they take their cues from a salty old fart who nods ever so slightly in certain directions to coordinate the whole symphony so that the programmers can abstract away everything about the yacht except speed, direction, and what they want for lunch.

We're working with Andy for the first Facebook app, and it's likely that the two of us would be the developer abstraction layer for the two programmers on the team. I am willing to do whatever it takes to make things easier for the programmers, even if that means wading into code and learning how to draw for the UI.

What I've Learned About Forming Teams
I've learned that it's not about me. I originally came to 3216 with the idea that we would all need to find the best people to work with/for ourselves, that it'll be an arms race to see who would be able to find the best talents. But the fact of the matter is that this isn't productive, and while it may make sense when you're hiring from a pool of willing developers, what we're really fishing in is a pool of equals, and so it would make less sense to hold interviews via email, and the like.

So instead of approaching people and asking them what they could do for me; I began approaching people and asking myself what I could do for them. What skills I had that could complement their abilities; what holes they had they I could help plug up. In simpler terms: I learned that the best way to form a good group was to approach the problem, asking: "how can I make their awesome abilities even more awesome?"

Things became a lot easier after I started thinking about it like that.

A Conclusion
I'm putting some of the above software engineering practices to the test, and I intend to document how it all turns out. There are a few other things, of course, such as how and what we're going to build - and what that is we can only tell, with time. I'm tired now. Off to bed.

Good night.

The First Problem Set

2010-01-12T01:30:00.000+08:00

Today was the first lecture in CS3216. It was awesome, and scary, and inspiring all at the same time. This isn't going to be a full post. Just going to scribble a quick series of thoughts that struck me on the way home.

Thesis statement: I believe Prof Ben has already handed us our first problem set, whether we know it or not:

Problem Set #1
You are in a group of 40+ people with different talents, personalities, and skill-sets. You are told that you must select three other individuals to form an app-development team. You are given four days to accomplish this.

Conditions:
Ideally, your team should have 1 programmer, 1 designer, and 1 marketer. (This is a loose condition - it is possible to have multiple people in multiple roles; or even in overlapping ones).

You are given an incomplete data set about the pool of 40+ people on which you must base your decisions. This data set consists of a Human Bingo sheet, a show and tell session, and a bunch of blog posts per person. Therefore, the most 'valuable' people in the eyes of this pool - as of the beginning of this problem set - would be those who are a) good orators/communicators b) good programmers and c) good artists. This is so because the above three properties are the easiest to communicate to the class within the context of the three activities. Other equally important qualities such as personality, compatibility and attitude cannot be easily communicated through Human Bingo/show-and-tell/blog posts.

All 40+ people are told that they should look for the 'best' people, to form the 'dream' team. This means that the three people you are looking for are themselves looking for three other people, one of which may not be you. If that isn't bad enough, some of these people may be seen as more 'valuable' than others, and may recognize this fact, and so would sit out the hunting to receive and evaluate multiple team offers.

You may not interview possible applicants, and all teams must be finalized by Friday.

What are you to do?

The way I see it, there are two possible approaches to this problem.

Approach 1: go out and find people, assemble a team, and have them work with you.

Approach 2: wait to be approached.

Approach 1 is largely dependent on your ability to persuade and convince three other people to work with you. If you are intent on working with competent people, you must first prove to them that you have something of equal or more value to bring to the team. Approach 1 allows you to gather the team that you think is best. It may also, however, backfire on you - especially if you do not have significant persuasive skills, or if you are not of high-enough perceived 'value'. If this sounds like a popularity contest, then it probably is - to a certain extent.

Approach 2 works for two kinds of people. The kind of person who believes that the best team may only be formed by luck, and the kind who is of high perceived 'value'. The approach does work if you are fairly 'valuable' in one of the above three areas of value; however there is a risk that you would be left out if you wait too long to respond.

Luck also plays a big part in this selection. There is no way of knowing if you might gel well as teammates and friends before actually trying it out during the development process. As mentioned earlier, the current data set does not include valuable pieces of information like personality, compatibility and attitude (along with other 'soft' intangibles). These are make-or-break qualities, and they may even override technical ability in terms of importance, if what we read from the past CS3216 blogs are true.

So. Presented with this problem, what do you do?

The answer: I have no idea. Not yet, anyway. And that kinda sorta really scares me.

Hold That Thought

2010-01-01T14:20:00.000+08:00

Yes, I know that in my last post I pretty much tore into Wave, but after a comment by Prof Ben I'm beginning to wonder if I've got it all wrong. The good Prof said:

suppose you have an API that allows for realtime communication between browsers. WHAT can and would you do with it? :-)

Now this got me thinking. In the introductory post to Google Wave, Lars Rasmussen said that Wave consists of three parts:

a product (the Wave UI you see and use today)
a platform (the extensions that add functionality to the Wave product)
a protocol (think: email evolved)

Now, say that I've got it all wrong. Say that Wave's value really is in the protocol, as Prof suggest?

I mean, think about it: Wave as a product is hopeless. It's dead on arrival. (for more on this, read my last post, or this and this and this).

Wave as a platform isn't much better off. It is, after all, building on 1)Wave as a product. Unless some third party uses the API to fundamentally change the way Wave works, or some enterprising group of programmers decide to fork the source code, this take on Wave is pretty much dependent on the first, and so is equally doomed.

(Caveat: there's a possibility, though, that some enterprising developer builds THE webapp of the decade on Wave API, and therefore Wave is saved entirely on the strength of that one webapp and everyone uses Wave because of they just can't live without that app and OMG you just have to try Wave because that one app is so bloody useful can DIE if don't use it!! Alright. You get the idea. I stop.)

But Wave as a protocol is remarkably interesting. With such a protocol, other developers who want to build real-time web applications no longer have to reinvent the wheel. Wave is pretty robust. And even if it's overloaded, as a product, with too many conflicting features, future developers may just pick and choose from Wave's feature-set to offer an easy-to-understand, useful little web-app (and sell it, and make money, and so on so forth).

The best thing about this take, though, is that it does seem aligned with what we know of Google's current Internet strategy. Google is intent on creating more value for Internet users, in so far as to (hopefully) bring more people online, and therefore - in the process - enabling Google to organize more of the world's information.

Wave as a protocol: now that's an idea to think about.

(And how silly of me not to have seen it earlier!)

The Problem With Google Wave

2009-12-30T18:30:00.000+08:00

Writer's note to self: too snarky. Reconsider tone for analytical pieces.

A few months ago my programmer friend, Max, and I started talking about Google Wave. The discussion began innocently enough. We were commenting on the CS3216 email we had all received, just a couple of days before, and the conversation eventually turned to Wave itself.

"But what is it used for?" I asked.

"Imagine!" he said, waving his hands in the air: "Imagine if we could use Wave's API to create a database, say, or a file, one in many many sets of computers. That way, everything we change in one computer can be reflected in all databases on all the other computers that are connected together, instantaneously!!"

And then he paused.

"But isn't that something you can easily do?" I said, frowning, "Using a program like, err, Dropbox?"

There was another pause as we stared at each other. And then we concluded our talk: he shrugged and said that it was Still Cool Anyway, and I agreed, and we both returned to our CS1231 assignment.

But here's the thing that's been bugging me, ever since I first heard about the project: I just don't get Google Wave. And the chances are good that you don't, either. What good is it for? How exactly do you use it? What exactly is it? I've had a Wave account for some time now, and while I've spent little time experimenting with it (let's just say I have exactly one friend who I can chat with, on Wave); I am starting to believe that Google's made a mistake with Wave, and that it would never catch on.

(But wait! ... hold your horses now. Last time I checked, boy, YOU'RE currently signed up for a module with LOTS of Google Wave development. You're not trying to ruin the party before it begins, are you?)

Well no I'm not. I'm not saying anything about Wave as a development platform; the same way I have nothing to add about Wave as a learning tool. Whether or not Wave succeeds as a web-app has nothing to do with the two factors above. But I do think that there's something fundamentally wrong with Wave, as an idea, and I do think that it's worth talking about, especially so before the course begins.

Email, reimagined
One thing we should get straight: the marketing for Wave was, I think, one of the best I've ever seen for a web-based software product. Take the video for example. Google's vice-president of Engineering walked in on stage and told the audience that he was going to show them a 'revolutionary new' product, one that 'does not look at all like it's in the browser', and that he hoped everyone present would 'be as excited about it as (we) are.'

Which is - when you look back on it - really nothing more than a heck lot of hype. I know this because it got me all excited about it. I think the space above my head exploded into a hundred squiggly exclamation marks and I ran to my browser and I opened a new tab and signed up for an invitation as soon as I could. I'm not sure how it was for the developers present - because the effect must've been a hundred times more powerful when you're there, in person - but I think that maybe, just maybe, some of them might've peed in their pants.

(And then the engineering team themselves came up, and all sorts of bugs happened, and Wave suddenly didn't look so cool as before, but still. Lots of people got crazy about it, and quickly.)

But the thing is that when I now come to think about it, I realize that all the excitement I felt was a direct result of the technology on show in the conference, and not about the project itself. I was excited by the non-browser behaviour so described by Lars Rasmussen. I thought it was really cool that you could type live and upload pictures and tag people, and I thought it was cool, too that they were building something that completely reimagined email as we know it: how email might've been, say, if it had been invented in this day and age.

Wait. Stop right there. What?!

Does anyone see what's wrong with this picture? Do you? Not yet? Alright then, let's take a look at the first blog post on Wave, at the Google Blog, on the original idea for Wave:

... (Jen) pointed out that two of the most spectacular successes in digital communication, email and instant messaging, were originally designed in the '60s to imitate analog formats — email mimicked snail mail, and IM mimicked phone calls. Since then, so many different forms of communication had been invented — blogs, wikis, collaborative documents, etc. — and computers and networks had dramatically improved. So Jens proposed a new communications model that presumed all these advances as a starting point, and I was immediately sold.

Two Problems With Wave
Problem #1. The most successful products in the world today are products that fulfill a need. This is true even if the need is something that your users do not yet know they have. So what need, exactly, does Google Wave solve? If you read the introductory post on Wave a second time, you'll quickly realize that the project says almost nothing about this need. In fact, Wave's creators are so silent on this one important detail that the bloggers at Lifehacker were forced to ask their readers the very question the devs had neglected to ask.

This lack of focus, then, begs the question: what was the dev team thinking?! If it seems that they're far more interested in the razzle and pomp of the technology (in this case, HTML 5, which Google has chosen as their replacement to Gears) then you may well be right. If you watch closely, the introduction post begins to read something like this:

So ... we looked at all the OLD forms of communication, and they seem, well, OLD. And so we're going to build a new one ... because, you know, we're bored here, and we're looking for a project, and, well, uh, we really REALLY think it's cool. Like REALLY!

The Rasmussen brothers are building Wave because they think it's cool. Does that sound wrong to you?! Does that sound suspiciously like something from - oh wait that's not possible, oh but you mean you're not - ahh sorry bout that then. Sometimes I confuse Google with the MIT Media Lab. I really should start noting the differences. Conceptually, though, inventing a whole new communications platform; remaking the world as you do it, even, sounds like a programmer's dream project. But practically Wave has got a long shot in winter. The way it is today, Wave seems more like Google's proof of concept for HTML 5 features than it does any plausible product.

Think about it, for a bit: what's so bad about email as it is? What is so terrible about IM that Wave must fix? Last I checked, both email and IM work perfectly well together (as in Gmail) and separately. Both cater to different ends of the communication spectrum, and both are good solutions to well-defined problems. Reinventing the wheel is all well and good, but if you want the Wave protocol to replace email, like Google does, then Wave has to be demonstrably superior in every way in order to achieve the sort of monopoly that Google imagines Wave to be.

And the thing is - the thing is, well, that Wave isn't demonstrably superior to email. Not for the majority of businesses out there, not for my tech-illiterate relatives, and certainly not for day-to-day text communication. Email and IM coexist simply because people have different uses for them, the same way people had different uses for writing letters and calling on each other in the days before the Internet. By making Wave an interactive, live medium, Google has removed all possibility of Wave as an email replacement. And by adding functionality such as embedding - which, I don't know, isn't that big a loss; VIDEO SPAM, ANYONE? - Google hasn't really proven to us that Wave is that much better.

(Note: there are problems with email which Wave solves, especially when it comes to collaboration, but I'll come to that in a bit).

So that was problem #1. There's a second problem, one that I'll call the problem of mappings. One of Wave's goals, as stated in the introduction, was to imagine what a communication platform would look like based on what computers are currently capable of, instead of imitating other non-electronic forms of communication. In simple terms, Wave's developers wanted to forget about the tools which we've created for the Internet in the past. They wanted to forget about email, they wanted to forget about IM, and they wanted to forget about wikis and blogs and real-time chatrooms. They wanted to come to the computer like a baby coming to a completely new toy - with no preconceptions - to create a communication tool based on what they saw.

And was this a good idea? Well, was Troy a good idea? Absolutely not! It is precisely because of this that Wave is confusing to so many people.

There is this idea in UI design that says that there should be a conceptual connection between a new object and a familiar one, in order for the newer object to be easy to use. We call this connection a 'mapping'. Some examples: we may say that a motorcycle has good conceptual mappings, because users are likely to have experienced riding a bicycle before. We may also say that email has good conceptual mappings, because people are familiar with the idea of writing and sending letters to each other. Therefore both a motorcycle and an email as concepts are easy to understand, because they have clear mappings to things people already know and use. In fact, if we look at the long history of technology, we'll quickly realize that things succeed only in so far as the mappings are concerned. If you have clear mappings to an existing technology, then your new product will be easier to understand, and therefore better poised to gain mass acceptance. Writing succeeded because it had clear mappings to speaking; snail-mail gained popularity because it had clear mappings to writing; and email became one of the most successful communication formats of the 21st century simply because it contained clear and useful mappings to the pen-and-paper letter.

The problem with Google Wave is that it has almost no mappings to anything that currently exists. It is a rethink, as opposed to an incremental upgrade, and in the history of technology rethinks are death traps to innovative products. In this particular case, Wave is a mishmash of features that appear to be thrown together merely for the heck of it, simply because its inventors came to the computer the way it was, saw its capabilities, and decided to throw it all together just because they could.

If that wasn't bad enough, Google's language regarding Wave is confusing enough to suggest that even its developers don't understand what a Wave really is. In the introductory talk Lars Rasmussen describes it as email and IM, reimagined; in another it is described as a communications protocol; and on the about page Wave is called a conversation/collaborative document hybrid. It could be that Wave is one or all of those things, but the ideas we have about any one of those individual elements are hard to reconcile with one another. For example, how is an email, which is static, reconcilable with IM (and how is that more useful than the sum of its parts)? Also, how is a shared document any more valuable when IM functionality is added to it? One thing's for certain: if Google keeps talking about Wave in such conflicted terms, there's no way in hell that a grandmother in Texas, for example, would give Wave a passing glance.

One Answer
One solution to this problem is for Google to drop its dreams of a replacement email protocol and instead rebrand Wave as a collaborative project-management tool. I told you earlier that email as a medium does have certain problems with collaboration, and that these problems may be solved by Wave. But the truth of the matter is that not one of the potential use cases described in Lifehacker's blog post cannot be solved by using other existing web applications. 37signals's Basecamp is a brilliant collaborative project tool, that is used by many existing companies to manage their online development teams. Campfire is a great group chat tool, optimized for organizational use, and equipped with a robust file sharing system (you may upload documents and files for the rest of your team, and the files will be displayed, inline, in your conversations for as long as the service exists). And Etherpad is a great livewriting application, built to allow multiple people to edit the same document, live on the web. Google could do well to release free alternatives to these software products, thus undermining an existing internet company (oops!), but at the same time creating more value for Internet users around the world ... in advancement of Google's long-term cause.

The Future
Is all lost? The answer to this isn't clear. It could be that Google Wave would, against all logic, live up to its hype. It could also be possible that Wave flops, completely, and is discarded as Rasmussen and co. leave the project to work on something (hopefully) more useful. Or it could even be possible that Wave turns out to be a sleeper hit - that it fails in its intended purpose as a communication platform and is then adapted for uses its creators never thought imaginable.

There is much hype and hoopla surrounding Wave these recent months. As an active agent in the digital fiction movement, I must note that quite a few are, at the moment, evaluating Wave as a possible platform for live digital storytelling. This is one use that I had not thought of, even though I've been thinking about and experimenting with web fiction for about four years now. Perhaps Wave's greatest success would be in a format nobody thought possible. And even then - I would suggest redoing the existing UI, because nobody - not even the fictional grandma in Texas - would want to use such a complicated, directionless thing.

On The Weird Blog Name

2009-12-29T21:51:00.000+08:00

A few things, before you call me out on the admittedly pretentious blog name: there's a story behind why I'm calling this blog what it is. (A story?! By gum, I'd already written you off as a hack! You can't be serious about this, can you?!)

But yes, I'm serious, and here's the story. This blog owes its name to Assoc. Professor Stephane Bresson, who taught CS1231 last semester. As I remember it, we were in a lecture on number systems, and on one of the last slides Mr Bresson threw up an image of a strange wristwatch. "Du yuu know what thees ees?" he asked us. (Mr Bresson is French, and he speaks with a rather quaint accent).

"Theeese ees a watch that displays the time ... in binary form! It is a watch for nurds. Do you know what ees a nurd?"

Some people were already turning in their seats, looking at each other, and grinning.

"Yuu don't know what a nurd ees? No?" - and Mr Bresson got all excited now - "YOU are a nurd! I am a nurd! We are all nurds! Because we are computer science students, we are nurds! Maybe ... perhaps, I should buy one of the watch for eech of you!"

And that stuck with me, it did, because it was hilarious.

Now I know that the syntax is all wrong (it should be if (isNerd) {return true;}, for Java) but I'm omitting the curly braces because it reads better, especially to non-programmers. Oh - and this reminds me - if you're a non-programmer and you're reading this, what the title basically means is: if you're a nerd, say yes! (which is, by itself, inherently nerdy, but cut me some slack, alright?)

If you don't know the difference between a nerd and a geek, look no further:

And if you want the font I used in the blog title - it's Monaco, which is the default programming font for the Mac (the colours, too, are the exact same ones I see when I open Textmate); people who'd like alternatives may find some here.

Hello World

2009-12-28T20:15:00.001+08:00

if (isNerd) return true is a blog about software.

It's also a blog created for this module I'm taking this year: CS3216 Software Development for Emerging Platforms.

What I expect to learn from this module
I want to learn kung fu. Like Neo in the matrix. Stick a spike up the back of my head, and pray I don't die.

Okay no, seriously.

I hope to learn a couple of things. I'm actually expecting the most valuable lessons from CS3216 to be the ones that I'd never thought of, but here goes anyway:

I want to learn team-based web development.
Web apps are relatively small products, so the teams working on such applications are usually groups of no more than 5 people. I want to know how it feels like to work in teams like these, because the dynamics are, as one might expect, quite different from typical software development. And while I've worked as the designer-half of a two man (development) team before, I'm still rather green around the ears, and am particularly interested in the challenges of working in a programmer/designer/marketer environment. (Curiously enough, 37signals, a premier webapp company, does most of its work in teams of three: one programmer, one designer, and one 'sweeper' - a guy who hops between both worlds.)

I want to learn how to launch under pressure
Startups regularly launch under pressure. The difference between that and CS3216 is that there's no risk of you going bankrupt in school.

I want to learn talent evaluation
One of the scariest things, I think, for me, is this idea that we'll have to pick people for our teams in CS3216. Recognizing talent and recruiting them to your cause is an important skill to learn, particularly so if you intend to work on a startup in your spare time (caveat: for the long run, because I'm beginning to become rather suspicious of startup founders who create their companies with an exit strategy in mind). At any rate, I'm determined to approach this part of the module with an open mind, because while it's intimidating and all it's still going to be rather interesting to see how we pick and choose our teammates. Snap character judgments? Now that's scary ... very scary indeed.

I'd like to meet new people
And this is plain simple. I mean, c'mon! CS3216 is an interdisciplinary module, no? That does usually mean a high concentration of clever crazy people, from all kinds of places.

In return:
I hope to do all I can to help my teammates, whoever they are, perform to the best of their abilities.

Right. It's late, and I've spent far too much time fiddling with the blog design. I'm off to bed.