iPhone and Apple TV

I have had a little time to digest all that has been written about the iPhone and Apple TV, and I think that the latter product will have more of an impact than the former.

What, huh!! Bear with me on this…

With the iPhone I think Apple, having redefined the portable music player market, is making a grab for the mobile device market. I think they have a good chance of getting there because the iPhone is so neat compared to the current competition. But the mobile market is much more established than the music market was when Apple entered it 5 years ago, and there is a lot more competition there too, competition which has deep pockets and which is not going to stand still. They are also going head to head with Microsoft who is becoming the dominant player in the mobile market with Windows mobile. While Apple may strike gold in the consumer space with the iPhone, I think it will be a lot harder to do so in the corporate market because there will need to be close integration with Microsoft products.

All this being said I think I will get an iPhone, not so much because it can play music (I already have two iPods) but because it offers good integration with the Mac (hence all my data), and because it provides adequate mobile internet access.

The device which is much more interesting to me is the Apple TV, with iTunes, that little device bypasses the normal delivery systems for television content, leaving the cable companies and the delivery system of traditional television networks high and dry. This delivery comes with the added frosting that there are (for the moment) no ads, and that I can watch what I want when I want, and I can go back to episodes I have missed. I may well start to watch television again. I cancelled my cable over a year ago when I realized that I had not picked up my TV remote for over six month. I think I did not pick up my remote because while I had 60+ channels, I did not want to have to wade through all the junk to get to the 2% that I wanted to watch. It just wasn’t worth my time.

All that being said, I think that Joost needs to be paid close attention to.


Lessons Learnt – Hiring

Hiring is always a subject of debate, and there are a lot of books/posts/opinions out there on how/who/what to hire.

For me it boils down to few simple rules:

  • Hire because you want to, not because you need to. Hiring someone just because you need to fill a seat is a recipe for failure. I have hired people in the past because I needed someone, a programmer, a graphic artists, whatever, and the pain of hiring the wrong person is much higher than not hiring at all.
  • Hire smarter than you. I have seen this one before, colleagues sometimes feel threatened when someone walks in the door who is smarter than they are and decides against them for some bogus reason.
  • Hire multi-skilled people. It is always good to hire people because they have multiple skills, that stands to reason. But you need to look for disparate skills which will be useful to you in the future. For example, if you plan to expand into the Japanese market, hiring a developer who is also fluent in Japanese makes very good sense.
  • Never hire based on phone interview alone. Always interview someone face to face. Human beings are social animals (sorry to be so base), and the phone is a very poor communication medium when you don’t know someone.
  • Fire quickly. If the person is not a fit, or they bluffed their way through the screening process (you have a screening process right?) or is clearly out of their depth, it is much better to let them good sooner rather than later. Delay does damage to the project they are on and to the rest of the team because they see that there is an issue (usually before management), and keeping them on is bad for morale. People will not fault you because you fired them, but because you did not fire them fast enough.

One of the better articles I have read on hiring were written by Joel Spolsky and can be read here and here.

Slice and Dice

I really enjoyed reading this post entitled “You Scaled Your What?” which talks about scaling, and stresses the point that there are multiple dimensions to scaling.

My rule of thumb with scaling is that if you can’t slice and dice it, it just won’t scale. What I mean by this is that if you cant slice your data, spreading it across servers and/or partitioning it, your system just won’t scale.

Slicing and dicing brings transactional scalability because you now have many more machines to process your data and to respond to searches. Of course this is dependent on the data actually being sliceable, but I would contend that very few real world data sets cant be sliced in one way or another, with lots of data sets being embarrassingly sliceable.

Slicing and dicing brings redundancy because you have mirrors hosting the same data, enough said.

Slicing and dicing allows you to deploy additional machines relatively easily and ramp up your processing capacity. This assumes that you made deployment easy, you did make deployment easy, right? In my experience, it is usually much simpler for operations to deploy a large number of smaller machines and great big machines which require lots of lead time to set up and stabilize. Operations also benefits because they have simple, cookie cutter machines to deploy and maintain as opposed to big monoliths where all hell usually breaks loose if something goes wrong.

What slicing and dicing does not speak to is productivity and feature ttm, but I would contend that those stem from good architecture and development process, which are hard to achieve but with big payoffs.

Lessons Learned – Picking Business Partners

Picking business partners when launching in a new venture is very difficult, and there is no secret sauce. Every situation will be different, but there are a few tennets which I would suggest form a base to build on.

You need to have things in common, unless there are things in common then it is a non-starter because you will find it very hard to communicate.

The converse is that you need to bring skills and knowledge the other person does not possess, you need to compliment each other. This is equally important to the previous point. If you both have the same skills, then you are just doubling the output and not enhancing it.

There also needs to be respect for each other’s skills and a balance. There is no room in a startup for people looking down on skill x or skill y because they are not as valued in their profession.

Along with mutual respect, there also needs to be a clear understanding by each party what their limitations are. There is nothing worse than having someone thinking they can do everything or take on every responsibility, because the reality is that they probably can’t. You need to focus on your strengths and learn to hand off stuff that is not a strength.

I am not sure that being best friends is important, but you need to be able to work long hours together without really annoying the hell out of each other.

Open communication is very important, and keeping it professional is also very important.

I am sure there are other things, it really depends on the individuals concerned, but this is the list I would start with.


Like a large part of Mac-dom out there, I follows the blogs pretty closely when his Steveness was presenting the Apple keynote yesterday, introducing the iPhone.

Of course the thing looks like a gem, and the integration with Macs has got to be better than that offered by my RAZR and my Palm, both of which suck pretty badly at it/

But, I was very interested by Henry Norr’s reflections on the keynote. It seems that there are a lot of questions yet to be answered and some notable shortcomings. That being said, I will certainly take a very close look at it when it does come out, because it does look better than most of what is out there.

Lessons Learned – Move On

In my previous Lessons Learned post, I mentioned how it was important to get code right because, most than likely, it is going to be in use for far longer than you imagine.

The flip side of this is that you also need to know when enough tinkering is enough and move onto the next thing. Value will not be created if the same bit of code is being re-written ad nauseam.

Lessons Learned – Long Life

Anything you do will have a longer life than you imagine. Hard to see when you whip up some table or some code thinking “this only needs to last us two weeks.”

Believe me when I say that it will likely still be running in six month’s time if not more. So it is worth taking the time to do it right, even if you need to do it twice or thrice. I have frequently put something together only to step back and see a better way of doing it once it is done. This is normal since there are almost always unknowns when you first start on something.

It is always best to take the time to do it right, rather than live with a botch for a long time.