On Treehouse

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

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!

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

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

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

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

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

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

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:

1. a product (the Wave UI you see and use today)
2. a platform (the extensions that add functionality to the Wave product)
3. 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!)