Flickr Badge

Friday, December 23, 2005

Workstation Ergonomics

"Setting up your computer may seem as easy as pulling up a chair and reaching for the keyboard. Yet positioning or using your computer improperly can lead to all sorts of injuries - from the short term discomfort of headaches to long term (and potentially debilitating) conditions like Carpal Tunnel Syndrome. Many people don't even realize that their pain is computer-related - until they learn proper work habits, and the pain disappears."

Healthy Computing has complete information on proper workstation habits - how to position the keyboard, where to place the monitor, how high the chair should be and lots more. If you want to avoid repetitive strain injuries after ten years, then it is time to apply proper workstation habits right now. For more, see the website:

Tuesday, October 18, 2005

60 million girls "missing"

The 2005 UNFPA report states that 60 MILLION girls are "missing" in Asia: How to Name It?

In Asia, at least 60 million girls are “missing” due to prenatal sex selection, infanticide or neglect.

[Also see this article :
'I have killed two daughters and will kill more'

Sunday, October 09, 2005

Mumbai Free Map Demo

I've been in the mapping mood lately (more on that later) and came across this recently: Mumbai Free Map Demo. It seems to be an attempt to do a Google Maps kind of app for Mumbai.

More information about this is available here.

Also check out this post which outlines the differences with Google Maps.

Thursday, October 06, 2005

Flock browser

Check out Flock. According to this BusinessWeek article, Flock has inbuilt support for blogging and putting bookmarks on and many more features. Sounds cool. Now we only have to see whether it really does all this or if it's just another startup trying to take advantage of the "Web 2.0" meme.

Tuesday, October 04, 2005

Sunday, October 02, 2005

3-5-7 (Part 2)

I wrote about the board game 3-5-7 in my previous post.

I wrote this program to as an experiment in AI. A simple board game seemed to be a good way to start. The program implements the minimax algorithm for determining the best move.

3-5-7 is a simple game, so the program can explore the entire problem search space. This means that if there is a winning move, the computer will find it.

3-5-7 also has a clear winner. Unlike tic-tac-toe, draws are not possible. Therefore, if there is no guaranteed winning move available, then the opponent has a guaranteed winning move irrespective of the move you make. In particuler, the player playing first has a winning move, so the first player cannot lose if the player plays a perfect game. Make a mistake however, and player 2 has a winning move.

When the computer has no winning move and is guaranteed to lose irrespective of the move it plays (provided the player plays perfectly), then how does it choose which move to make? Against an experienced player who knows how to play a perfect game, it does not make a difference which move is played. However, against a novice, some moves are more adept at inducing mistakes.

This is where the Strategy classes come into play. The program implements two strategy classes - RandomStrategy and FilterStrategy. RandomStrategy randomly chooses a move. FilterStrategy gets rid of moves that leave the board in obvious states, and chooses from the remaining moves. This has the effect of increasing the chance that the novice player will make a mistake and give the computer a winning move.

To implement other algorithms for choosing a losing strategy, we just need to implement another strategy class and set the strategyClass variable in the first line of the main program to point to this class.

The boardstate variable is initialised to [3, 5, 7] in the main program. We can change this to try playing with different number of coins. Change it to [21, 23, 25] and we can see how slow the AI is because it no longer becomes feasible to search the whole tree. An interesting evolution would be to limit the depth of the tree searched by the AI and see how it performs. Pruning the search and implementing heuristics are other possible improvements.

One interesting technique to learn the perfect moves is to play the computer against itself. Start two instances of the game. Play first in one, and play second in the other. Feed in the moves played by the computer in the first game as the player move in the second game, and vice verca (in effect playing the computer against itself). Soon, you will get a hang of the better moves.

This post is a part of the selected archive.


3-5-7 is a simple two player board game. There are three rows of coins. The first row has three coins, the second has five and the last row has seven. A player can take any number of coins from one particular row. The player to take the last coin on the board loses.

This python program plays 3-5-7 with a human opponent. To run it, you need the python interpreter. My version is 2.4.1, but it should work with previous versions as well.

If you are copy-pasting this somewhere, then remember that whitespace in python programs are significant, so all those tabs and spaces should remain as they are!

[I would much rather upload this somewhere than put the source in a blog post. Any good uploading services available that allow you to upload small files? Preferably no intrusive ads, sign-ups etc]

# Constants


# Error Class

class InputError(Exception):

# Strategy Classes
# Strategy classes are the really interesting part of this program. They determine what
# the computer will do when the computer cannot play a guaranteed winning move. Some
# moves are more likely to induce mistakes than others. Each strategy class uses a
# different strategy to choose between two losing moves
# All classes implement getBestMove which returns the best move from a list of moves
# for the given boardstate

# Strategy to randomly select one of the moves
class RandomStrategy:
def getBestMove(self, boardstate, moveList):
# toss a coin ;)
import random
selectedIndex = random.randint(0, len(moveList) - 1)
return moveList[selectedIndex]

# Strategy which filters out moves which leave the board in simple states
class FilterStrategy:
def hasOnlyOneRowLeft(self, boardstate):
if (boardstate[0] == 0) and (boardstate[1] == 0):
return True
if (boardstate[1] == 0) and (boardstate[2] == 0):
return True
if (boardstate[2] == 0) and (boardstate[0] == 0):
return True
return False

def hasTwoRowsLeft(self, boardstate):
if (boardstate[0] == 0):
return True
if (boardstate[1] == 0):
return True
if (boardstate[2] == 0):
return True
return False

def hasMirrorRows(self, boardstate):
if (boardstate[0] == boardstate[1]):
return True
if (boardstate[1] == boardstate[2]):
return True
if (boardstate[2] == boardstate[0]):
return True
return False

def getBestMove(self, boardstate, moveList):
import random
def move(board, move):
newboard = board[:]
row = move[0] - 1
coins = move[1]
newboard[row] = board[row] - coins
return newboard

filterList = [self.hasOnlyOneRowLeft, self.hasTwoRowsLeft, self.hasMirrorRows]
boardstateList = [(x, move(boardstate, x)) for x in moveList]
# filter out cases which leave board in simple states
for filter in filterList:
newlist = [x for x in boardstateList if not filter(x[1])]
# if we are left with nothing, unfilter
if len(newlist) == 0:
newlist = boardstateList
boardstateList = newlist
# now take one of the remaining moves
selectedIndex = random.randint(0, len(boardstateList) - 1)
return boardstateList[selectedIndex][0]

# Output routines

def printWelcomeScreen():
print "_" * 50
print "WELCOME TO 7-5-3"
print "_" * 50
print "Rules: In this game there are three rows of coins."
print "The first row has 3 coins, the second row has 5 "
print "coins and the last row has 7 coins. In your turn,"
print "you can pick up as many coins as you like from any"
print "one row. You must enter your move in the format"
print "row:number where row is the row you want to pick"
print "up from and number is the number of coins you"
print "would like to pick up."
print "For example enter your input as 2:5 if you want"
print "to pick up five coins from row 2"
print "The player to pick up the last coin is the loser"

def drawboard(boardstate):
print "_" * 50
print "Row 1 : [" + str(boardstate[0]) + " coins]",
print " " + boardstate[0] * "O "
print "Row 2 : [" + str(boardstate[1]) + " coins]",
print " " + boardstate[1] * "O "
print "Row 3 : [" + str(boardstate[2]) + " coins]",
print boardstate[2] * "O "

def displayMove(player, move):
print "_" * 50
print " -> " + player + " moved " + str(move[1]) + " coins from row " + str(move[0])

def displayWinner(winner):
print "_" * 50
if winner == COMPUTER_WINNER:
print "The computer is the winner"
print "You are the winner"
print "_" * 50
raw_input("Press Enter to quit...")

# Input routines

def parseInput(input):
tokens = input.split(":")
if len(tokens) != 2:
raise ValueError
row = int(tokens[0])
numberOfCoins = int(tokens[1])
return (row, numberOfCoins)

def getInput():
input = raw_input("Enter your move: ")
move = parseInput(input)
return move
except ValueError:
raise InputError("Input should be of the form row:num. For example 2:3 means take 3 coins from row 2")

# Game routines

def makeMove(boardstate, move):
row = move[0] - 1
numberOfCoins = move[1]
if (row < 0) or (row > 2):
raise InputError("You must enter a row number between 1 and 3")
if numberOfCoins <= 0:
raise InputError("You must pick up at least one coin")
if boardstate[row] < numberOfCoins:
raise InputError("That row has only " + str(boardstate[row]) + " coins, so you cannot pick up " + str(numberOfCoins) + " coins.")
boardstate[row] = boardstate[row] - numberOfCoins
return boardstate

def doPlayerMove(boardstate):
validInput = False
while not validInput:
move = getInput()
boardstate = makeMove(boardstate, move)
validInput = True
except InputError, args:
print "Invalid input. " + str(args)
displayMove("You", move)

def isGameOver(boardstate):
if (boardstate[0] == 0) and (boardstate[1] == 0) and (boardstate[2] == 0):
return True
return False

# Computer AI code

def simulatePlayerMove(boardstate, depth):
global strategyClass
bestMoveList = None
bestPoints = None
for row in [1, 2, 3]:
for coins in range(boardstate[row-1], 0, -1):
currentMove = (row, coins)
newboard = boardstate[:]
makeMove(newboard, currentMove)
if isGameOver(newboard):
if (None == bestMoveList):
bestMoveList = [currentMove]
bestPoints = 100
(move, points) = getBestComputerMove(newboard, depth+1)
if points == 0:
return (currentMove, 100-points)
if (None == bestMoveList) or (points < bestPoints):
bestMoveList = [currentMove]
bestPoints = points
elif points == bestPoints:

bestMove = strategyClass.getBestMove(boardstate, bestMoveList)
return (bestMove, 100-bestPoints)

def getBestComputerMove(boardstate, depth):
global strategyClass
bestMoveList = None
bestPoints = None
for row in [1, 2, 3]:
for coins in range(boardstate[row-1], 0, -1):
currentMove = (row, coins)
newboard = boardstate[:]
makeMove(newboard, currentMove)
if isGameOver(newboard):
if (None == bestMoveList):
bestMoveList = [currentMove]
bestPoints = 100
(move, points) = simulatePlayerMove(newboard, depth+1)
if points == 0:
return (currentMove, 100)
if (None == bestMoveList) or (points < bestPoints):
bestMoveList = [currentMove]
bestPoints = points
elif points == bestPoints:

bestMove = strategyClass.getBestMove(boardstate, bestMoveList)
return (bestMove, 100-bestPoints)

def doComputerMove(boardstate):
(bestMove, status) = getBestComputerMove(boardstate, 0)
boardstate = makeMove(boardstate, bestMove)
displayMove("Computer", bestMove)

# Main Program

# Change this to the strategy you want the computer to use
strategyClass = FilterStrategy()

boardstate = [3, 5, 7]
playfirst = raw_input("Do you want to play first? (Y/N) : ")
if len(playfirst) == 0:
playfirst = "Y"
if playfirst[0].upper() == "Y":
firstMove = doPlayerMove
firstWinner = PLAYER_1_WINNER
secondMove = doComputerMove
secondWinner = COMPUTER_WINNER
firstMove = doComputerMove
secondMove = doPlayerMove
secondWinner = PLAYER_1_WINNER

winner = GAME_NOT_OVER
while True:
if isGameOver(boardstate):
winner = secondWinner
if isGameOver(boardstate):
winner = firstWinner


This post is a part of the selected archive.

How IBM Conned My Execs Out Of Millions

Interesting link: How IBM Conned My Execs Out Of Millions

Wednesday, September 28, 2005

Bill Jay

After 25 years in academia, I have suffered through more than my fair share of graduation speeches complete with all the usual cliches, pabulum and platitudes strung together in an endless stream of tedium. In the unlikely event that I would ever be invited to address the graduates, I would give the shortest speech on record:

Dear Graduates,
Find something you love to do.
Get good at it.
Hope, but certainly don't expect others will appreciate it.
Then, just possibly, you might be able to make a living at it.
Thank you and good luck.

-- Bill Jay in Lenswork magazine, Issue 54

This post is a part of the selected archive.

Tuesday, September 13, 2005

The Hindu RSS Feeds

[via Ta Daa! 4.0]: The Hindu has RSS feeds of all its sections. Finally, a convenient way of accessing serious news (No, indiatimes & rediff don't count as serious news)

Sunday, August 28, 2005

IGN: GBA Micro

IGN reviews the GBA Micro:

You already know that the Game Boy Micro is small when you hear people tell you that it's just barely bigger than the cartridge that fits into it, but you don't really get a sense for just how small it is until you get your hands on it. Your thumb just about dwarfs it. The AC adapter for the system is nearly as big as the system it charges -- the charger is slightly thicker, almost exactly as tall, and a little more than half as wide. The whole system is smaller than just the screen on Sony's PSP. It almost fits inside a Nintendo DS game case. We're talking very, very small.

Sunday, August 21, 2005

Friday, August 19, 2005

Weird formatting issues

If you've visited the blog in the last month or so, you would have noticed a weird CSS formatting issue which caused all the posts apart from the latest one to be shifted downwards, leaving a huge bit of white space. I decided to look at it today, and saw that it was a stray div tag with clear:both style causing the problem, but it seemed to be added automatically by blogger. After a lot of hair pulling, I came across this: Blogger Buzz: A Layout Solution

Evolution of Programming Languages Poster

We also printed out and put up this poster in the office: Evolution of Programming Languages Poster

Post-it Pacman

Something we did at the office: Post-it Pacman

Thursday, August 11, 2005

Opera Mini

All this while, Opera has mainly targetted higher end phones for their mobile browser. Today, they released Opera Mini. Opera Mini is a stripped down version of Opera which will run on lower end phones. It's written in Java, so the phone needs Java support. Instead of doing all the processing on the client (like they do in their full mobile browser), they have a proxy server that converts the data into a format suitable for the phone, and the client just renders that.

This is all VERY similar to the initial WAP idea, with one major difference: while the original WAP spec needed content developers to develop in WML, with Opera Mini you can visit the very same HTML sites that you do on your desktop. This is a big difference. One of the main reasons that WAP has not really caught on is because of the lack of quality mobile content (remember, you can't view HTML pages). The WAP 2 spec rectifies this by adding support for XHTML and CSS, but all the processing is done by the client. Opera have combined both ideas in Opera Mini.

There are still a number of potential pitfalls. Another reason why mobile browsing hasn't caught on was because of slow and expensive bandwidth. Yet another reason has been difficulty in reading on a small screen and clunky input via a telephone keypad. Neither of these have been solved. Opera uses compression and small screen rendering (which modifies the page to accomodate a small screen) to try to solve these problems, but the solutions have only been okay. I'd love to try it out to see how it scores on these points.

Opera Mini is only available in Norway at the moment (no idea why). Can't wait to try it out when it releases here.

Wednesday, August 10, 2005

Tuesday, August 09, 2005

Skill based promotions

I wrote mentioned a skill based promotion system in my essay yesterday. I've fleshed it out a bit more. Here is my current thinking on this topic.

When deciding whether to promote somebody, ignore past performance. This sounds like a radical idea, but it's not.

A promotion usually signifies some change in role. The best person for a project management role is not always the best programmer in the team. Past performance shows that they have the skills to do well in their current role. What is important is that the person has the skills required to perform well in the new role.

Instead, consider a skill based promotion. Establish the skills required for different roles in the organisation. Promote people when they acquire those skills.

Such a system is also transparent: Everyone knows where they stand and what they need to do to achieve a promotion.

Here is a plan on how to implement skill based promotions -
  • Write down a list of skills required for each role - apart from promotions, these lists of skills will also help in hiring
  • Provide resources to enable employees to acquire those skills
  • Promote them when they have acquired the relevant skills

How can we come up with a list of skills? Here is one example -

Key Skills Required -
  • Thorough knowledge of the programming language
  • Refactoring
  • Knowledge of a unit testing framework
  • Project architecture and design skills
  • Estimation methods
  • Design patterns
  • Understanding of algorithms
  • Code reading skills

Project Manager
Key Skills Required -
  • Identifying and managing project risks
  • Estimation methods, formal and informal
  • People and communication skills
  • Knowledge of at least one traditional process and one agile process
  • General management skills
  • Good technical knowledge to understand problems faced by the team (Although this is not strictly required, programmers do respect their managers a lot more if they are technically oriented)
  • Some amount of domain knowledge
  • Basic understanding of the target end user - this is needed because the project manager is the user advocate in the team
  • Understanding of the technical environment - source control, testing methods used etc

Once the lists of skills have been written down for various roles, the next step is to help your employees acquire it. There are three ways to do this -

  • Allowing them to attend seimnars, workshops and conferences
  • Filling up the company library with relevant books and magazines
  • Enabling them to form ad-hoc learning groups

For my views on these three points, see my previous posts on creating ad-hoc groups and modes of learning.

One problem with this method is that there are only about 2-3 different roles available in project development, and thus reduced scope for promotions. It will also take a long time to acquire all the required skills from scratch.

The solution is to create intermediate positions when a part of the skills have been acquired. For example the above list says that a developer needs 8 key skills. There could be an intermediate promotion when 3 skills have been acquired, and another one when 6 skills have been acquired. Here is an example of such a ladder:

  • Developer [0/8 skills]
  • Senior Developer [3/8 skills]
  • Technical Designer [6/8 skills]
  • Senior Technical Designer [8/8 skills]

And for Project Manager:

  • Project Lead [5/9 skills]
  • Project Manager [9/9 skills]
  • Program Manager [9/9 skills + sucessful completion of at least two projects]

The above are just examples, and should be tweaked as required.

In my opinion, such a skill based promotion system is superior to a performance based promotion system.

This post is a part of the selected archive.

Monday, August 08, 2005

Merit Based Pay

Conventional wisdom tells us to take the top performers and reward them highly. The theory goes that if they aren't recognised and rewarded, they will soon leave to better opportunities elsewhere. Even if they don't leave, they will soon be demotivated and put in an effort comparable to the weaker performers. After all, the reward is going to be the same!

Conventional wisdom is wrong.

Do not reward the better programmers any more than the weaker programmers.

By rewarding better programmers, you place each individual in direct competition with the others. The easiest way to get to the top of the stack is to keep ones knowledge to oneself and stop helping others. Not surprisingly, a team can quickly fall apart. A quality team needs cooperation, not competition. Spread of knowledge benefits the entire team, and vastly increases the chances of delivering higher quality software.

The issue of competition and cooperation is a complex one, which deserves an essay on its own. In the meantime, consider the following extract from the book Peopleware:

Internal competition has the direct effect of making coaching difficult or impossible. Since coaching is essential to the workings of a healthy team, anything the manager does to increase competition within a team has to be viewed as teamicidal. Here are some of the managerial actions that tend to produce teamicidal side effects:

  • Annual salary or merit reviews
  • Management by objectives (MBO)
  • Praise of certain workers for extraordinary accomplishment
  • Awards, prizes, bonuses tied to performance
  • Performance measurement in almost any form

If you haven't read Peopleware yet, do so. It's one of those books that will completely change your perspective on software development.

Besides, how do we find who the best performers are? Should we count lines of code written? What if someone provides an elegant solution that takes only half the number of lines of code. Are they less productive? Or should we look at bugs per hundred lines of code? Does that correlate with programmer quality? Or does it just encourage programmers to mark bugs as "Invalid" or "By design" instead of fixing it, so that it does not count against them? Every manager's dream is to have a simple metric that can be used to quantify the quality of the programmer. Unfortunately, there is still no easy way of measuring programmer quality.

In this ITCoversations interview, Joel Spolsky talks about a team member who didn't seem to do anything. However, every team he was in succeeded. It turns out that he spent most of his time teaching and mentoring the other team members so that they could do a better job. All his team members loved having him on the team, but management was on the verge of firing him because the performance metrics showed him as the weakest performer.

One thing is clear: Its hard to measure the value added by a programmer to the team, its hard to measure who the best programmers are, and even if you know who they are, its hard to come up with some method of rewarding them without heavy side effects. But what is the alternative?

Is it really practical to say that we will reward the best programmers as much as the worst? What about the best people leaving the company or getting demotivated? What happens to employee morale when they realise that even if they put in extra effort, they will not be rewarded any more than if they had put in their normal effort? Ahh, the complexities of the real world.

The best solution to this tricky situation is to ensure that you don't hire weak programmers. It's tempting to lower your standard when you desperately need programmers, but this can have serious long term implications.

Next, try to ensure that the key motivating factor for your employees is not a reward. People should want to put in an extra effort because they want to deliver quality software and see the project succeed, not because they want some reward. It's the project manager's responsibility to bring about this change of mindset.

Finally, have a clear and consistent promotion system. Promotions typically look at skills rather than performance. Establish the skills required to move up a level. Then promote people when they achieve that skill level. This provides a sense of progression without breaking up the team.

Some other solutions are provided by Mary Poppendieck in this excellent essay [PDF] for Better Software Magazine.

No matter which solution is adopted, managers must be careful. By attempting to optimize individual performance, they can end up sacrificing team performance. This is a risk that must always be kept in mind.

This post is a part of the selected archive.

Tuesday, August 02, 2005

Source Insight

Source Insight is THE BEST code editor I've seen. It is totally, staggeringly, awesome. Especially if you are coding in C. It has pushed vim onto No.2 on my list now. It's way better than VC++. Much better than eclipse.

I've not used IntelliJ so I can't comment on that. I've heard a lot of good things about it, so if you are into Java programming you may want to investigate it along with Source Insight. But for C programming, it simply blows everything else away.

Now, VC++ and eclipse may have more features, but this still beats them. Why? It provides contextual information about whatever symbol is under the cursor. It makes navigating to different functions a snap. It can keep many, many files open at a time. And its FAST. Did I say FAST? I meant amazingly, blindingly FAST. Eclipse can barely run on my system, let alone allow me to keep twenty files open at a time. Source Insight lets me do it.

Did I mention smart rename? It allows me to rename a variable or function name, and it will rename the function everywhere its called. I know it's there in eclipse, but eclipse is such a slow behemoth that I just can't stand it.

Forget coding. Source Insight make READING code so easy. I can travel between various functions in seconds. I can see where all a function is called from. It formats the code beautifully. I can see function names and variable names so easily. They just pop out when you're looking for them.

Oh, and did I mention smart searching? Smart searching allows you to search symbols from the entire project. So you dont have to remember which file contains the function you want to see. What is more, you can type just a few characters of symbol to see it. That's available everywhere, right? Not when those characters can be from the middle of the function or variable name. Still, its been done in other IDEs. But not when its a similarity search, so you can search for "styleAdd" and it will find "displayAddStyleProperty". This is great when you don't know the exact name of the function but you have an idea that its got something to do with styles. This feature alone makes Source Insight more worthwhile than anything else.

Check out the trial version. You can download it here.

I don't use IDEs to read and write code anymore. I just use them for compiling and debugging. Source Insight actually makes me enjoy using it. This is how software should be written. It's awesome. I'm converted.

This post is a part of the selected archive.

Friday, July 29, 2005

Index of learning styles

Tying in with my previous posts on learning styles, I just came across this page which has an index of learning styles. From the website:

The Index of Learning Styles is an on-line instrument used to assess preferences on four dimensions (active/reflective, sensing/intuitive, visual/verbal, and sequential/global) of a learning style model formulated by Richard M. Felder and Linda K. Silverman

Thursday, July 28, 2005


There has been a lot of talk recently about Django, a new web framework written in Python. It looks awesome, a lot like rails. I really should take a look at this sometime. Sometime soon.

Wednesday, July 27, 2005

Ad hoc groups

Sachin posted an interesting comment about learning in companies.

One of the things I've noticed when talking to people is that most [Indian] companies do not take any steps to nurture adhoc groups. These are groups where like minded people can get together and talk or do side projects. Companies can create an environment where people can form such groups by themselves and then just sit back.

If you look at many of the US software companies (Google, MS etc) there is something there which causes people to do side projects and spread knowledge all the time. If one guy finds something cool, pretty soon there are a bunch of people discussing it.

Compare that with my experiences here. If anyone talks about some interesting topic, not connected with work, the reaction is something like "oh ok," rather than "cool, lets find out more about that." Or if someone decides to do something interesting, not connected with work, the first reaction is "whats the use" rather than "cool! lets do that this saturday".

Why is that? Is it that there are not many doer type people in Indian companies? Or is it because the company culture doesn't enable them to actually do anything? It is probably some combination of both I would think.

It's not like this in all companies of course (eg: Yahoo Bangalore), but its true in a depressingly large number of them.

What can be done about this?

This post is a part of the selected archive.

A Visit to Adobe

Check out cool tour of Adobe's San Jose offices: A Visit to Adobe

Tuesday, July 26, 2005

The different modes of learning

I've been thinking about this topic a lot over the last couple of months. It is a topic that I'm figuring out with my team. I'm just going to throw it out and see what the feedback is like.

I’m going back to my college days for this the first part of this essay. What I want to discuss is the different modes of learning. This will probably come as no surprise to most of you: Different people learn through different means.

Some learn by listening. Remember people who just sat in class and absorbed the entire lecture ? They learnt by listening. Then there are those who learn by writing. They take notes. Some people learn by reading. They just sleep in all the clases, then go home, read the text book and ace the exam. Some learn by talking. They need to discuess the topic with someone else to clarify their thinking. Finally, we all know that student who could write great programs on the computer, but could barely follow what was going on in class. They learnt by doing.

These five categories represent the different modes of learning. [These are actually a combination of modes. For more on the theory, check out these links - 1, 2, 3]. They are not mutually exclusive. Some people can learn in multiple ways, but most people have one dominant mode of learning and other minor modes of learning.

Think back to your college batch, and you would find a few classmates who fit each of the above categories. The college environment is designed to present multiple methods of learning. You can either listen to the lecturer, try out excercises, attend lab sessions, talk to your classmates about a topic, or read the textbook.

Now, someone is going to point out that (in most of India at least) lecturers are often recent college graduates who couldn’t get any other job, that the textbooks are written to maximise your exam score rather than teach anything, most students take down notes verbatim without any understanding and the labs are underfunded relics. This is a topic for another day. For now, lets just assume that they support all methods of learning.

Let’s get back to the present now.

Scenario I: Your company has a training programme under which they have called someone to give a seminar on Design Patterns. You’re a Project Manager. Madhav, a member of your team, will be doing some design work soon, so you send him over to attend the seminar. The only problem is that Madhav learns by reading, not listening. Not surprisingly the seminar is extremely boring for him and he sleeps through it.

Scenario II: You are working on a new project and have just recieved a thick list of requirements. You pass the requirements to Priyanka, the lead programmer, and ask her to take a look. The problem is, Priyanka learns by talking, not by reading. The next day, the coversation goes like this:

You: So did you have a look at the requirements I passed you?

Priyanka: I had a look, but they look complicated. Can we have a meeting to discuss them?

You: I’m busy right now. I’ll be back in two days to check on your progress.

2 days later…

You: So how are the requirements? I need to give an estimate for the completion date this evening.

Priyanka: I’m not sure I understand it. Can we discuss it?

You: You still don’t understand it? I gave you two extra days. What more do you want? Meetings are just a waste of time. Can’t you just read it and give me an estimate? I need to give an estimate today.


Meanwhile, Scott Adams is drawing you in the next Dilbert strip.

Most managers don’t really understand the modes of learning of their team members. If Priyanka learns by talking, the manager should know it and let her talk about the requirements. Forcing her to read the requirements will go nowhere. Similarly if Ramesh likes to read, his manager should pass his some reading material before he attends the seminar. The primary responsibility of a manager is to enable his or her team members to do their work as best they can, and knowing their learning modes can help with this.

Companies also like to talk about how employee oriented they are, and about their professional development policies, but in most cases this just means that they shove their employees through a couple of seminars a year, just because they have to.

Real professional development is a lot more than just sending everyone to a few seminars. Companies need to take a hint from colleges where most of the real learning takes place. They need a good library where the readers can hang out. They need cool co-workers so that the talkers can talk with each other and learn. They need ad-hoc groups of people who learn by doing to get together and do side projects. They need to create internal blogs so that the writers can write stuff, and of course, the good old seminars for the listeners to attend.

Any comments? How is it at the companies you work (or worked) at?

This post is a part of the selected archive.

Monday, July 04, 2005

NASA - Deep Impact

Check out these pages on the NASA Deep Impact mission. The mission was to hit the comet Tempel 1 with an impactor to clear the top layer of the comet. The spacecraft then makes measurements of the chemicals which are underneatg the comet's top surface. Cool huh?

Anyway, latest news is that the impactor has successfully hit the comet Tempel 1. Check out this image of the impactor colliding with the comet. The next phase is for the Flyby spacecraft to make its closest approach to the comet. Then the press conference in a few hours time.

Saturday, July 02, 2005

Counting The Miles

Counting The Miles: "The point is not that customers demand it or don't demand it, because that's absolutely not the viewpoint of Honda. When you are a philosophy-driven company, you don't ask the customer if they agree with your philosophy."

Friday, July 01, 2005

TheFeature :: The End of the Road

Just read todays article that TheFeature is going to be closing after 5 years.

TheFeature was an awesome site on mobile technology. It was not an ordinary news site, but featured a number of excellently written and thought provoking articles by some very talented writers.

From the site:

Now is the time for us to step back, and let the conversation and community move forward on its own. It's been a great ride, and we're glad that everyone could join us. So, would the last one out please turn off the lights...

For those who used to visit it, see the comments for links to the personal blogs of the various authors.

Tuesday, June 28, 2005

I am a statistic

Take the MIT Weblog Survey

I recently took the MIT Media Lab Blogger Survey. I am now a statistic :)

From jdk

Friday, June 24, 2005

How frequent should the delivery be?

In a previous post I had written about frequent delivery. Sachin asks in this comment how likely it is that a customer would be willing to check delivery after delivery. This is a good question thats worth going into some more detail.

Customers worry about two things: (1) Is anything progress happening in their project and (2) is it going to turn out the way they want. The worst nightmare for a customer is to not hear anything about the project until the end when they are told its only 50% done, and then they wait more time only to see the final product and find it unusable. In short, they want visibility into the project.

Now, different customers want different amounts of visibility. If a customer doesnt care if they project succeeds or not, they may want only one delivery in the end. At the other extreme, some customers may be willing to dedicate one person for the entire duration of the project to see how it is going. In Agile terminology, this is called having an onsite customer. Ideally, this would be the best situation, but it's not always possible. These are the two extremes. Somewhere in the middle are customers who want to see the project once in a while, if only for their peace of mind.

The ideal delivery cycle depends on two factors: how often the customer wants to see the progress, and how often you can make a delivery.

If it's a web based project, a delivery cycle of 3 weeks is possible. If it's a complex project with lots of deployment for each release, the delivery cycle will be somewhere around once in 3 months, which translates to around 4 deliveries for a year long project. If you are creating a product, the "customer" may be the QA team or the evangelist/stakeholder for your product. They may be willing to spend more time looking over the software.

Its up to the team to negotiate a suitable delivery cycle depending upon the customers willingness, the complexity of project deployment and how fast the team can add and test features.

In they end, the customer is paying for the software, so they would be definately willing to see it before the final delivery, especially if they are told that this increases the chances of a successfull product. Most customers have gone through projects with no visibility with disaster at the end and they would be totally thrilled that someone is actually willing to show them the product as it comes along.

This post is a part of the selected archive.

Thursday, June 23, 2005

Statue at Salisbury Cathedral

This statue is from the cathedral in Salisbury, England. Construction on the cathedral started in 1220 AD. The cathedral has the tallest spire in England at 123 meters. It also has one of the oldest working clocks in Europe. For more information, see this wikipedia article.

Wednesday, June 22, 2005

Truck Factor

One of the more informal metrics (if you can call it that) is the "Truck Factor" of the team. The Truck Factor measures the amount of spread of knowledge within a team.

Formally, the truck factor is the number of people that need to be hit by a truck before the project is in serious trouble. Of course, they don't actually need to be hit by a truck, they could leave the company, fall ill, or take a vacation.

The idea is that if only one or two people know the critical components of a system, then the project is in serious trouble should they leave. A Truck Factor of one is the worst, with most of the critical knowledge with just one person. Ideally everyone in the team should know every part of the system, but thats not very practical. An achievable goal is that at least 25% to 50% of the team knows any one component. Hopefully it won't be the same 50% who know every component :).

Small teams of under 10 people usually target a truck factor of 4-5 for most parts of the system (thats around 50% of the team). Larger teams will probably target a truck factor of around 8 (which would probably be around 25% of the team). This means that should a couple of critical people go on vacation or leave the company, there are enough people in the team who can cover for them.

Ironically, smaller teams usually have larger truck factors compared to larger teams. In teams of 5-10 members, there is a high chance that most of them know most parts of the system, with only a couple of modules having a low truck factor. In teams with above 20 people, chances are that a few people at the top (designer, architect, lead) know the system thoroughly and the rest only know about the couple of modules that they worked on. Should these people leave at around the same time, the project could be in serious trouble.

One of the things that we have been working on is increasing the truck factor. Every once in a while, we target areas with a truck factor of one and that person then gives a seminar to the rest of the team. Not only does it help with knowledge sharing, but it also means that the person can take a vacation without worry.

This post is a part of the selected archive.

Sunday, June 12, 2005

Trip Photos

I'm back from my vacation. I've uploaded some photos to flickr. You can either click the thumbnail images on the top of this page to see the most recently uploaded photos, or click here to access the entire photostream. Most of the photos are from London and Paris, but a few are from other places.

I should add a small note that the photos that I've uploaded so far are only the photos that I really liked (around 15 I think), so although I did take photos of the popular sights (18+ rolls of film/slides), they have not been uploaded.

Friday, May 27, 2005

Why did we choose Crystal Clear?

Gaurav asks in this comment why we chose Crystal Clear.

The reason is simple. We wanted a process that would actually improve the work we did. There are a lot of companies that claim to be CMM-Level 5 and what not, but in actual reality they don't really follow the process. It's only when the audit comes around that everyone pretends to be following the process. We didn't want this to happen.

Most processes are high discipline. They are great in theory - if you followed everything perfectly, then you would get results. But not many people actually follow the process, because it is so much of a pain to do that. So either the process lies around unused or you have a "process department" to force everyone to use the process, neither of which is the right solution.

Crystal Clear is designed to be followed. It just has the three rules (or properties) I mentioned in the previous post. If you take two teams, one following a high discipline process and one following Crystal Clear, then chances are the one following the high discipline process will have better results. However, take a team which is supposed to be following a high discipline process, but is actually not following it and compare with a team following Crystal Clear, then the advantage goes to Crystal Clear.

So, the question was would we prefer to have a great process that no one follows, or a simple process that everyone would like to follow? For us, the answer was a no-brainer, and we went with the latter.

Another factor was that many high discipline process do not scale down easily to small teams. Crystal Clear follows the opposite path, it is optimised for small teams and scales up for higher team sizes.

Finally, the third property of crystal clear (reflective improvement) ensures that any changes to the process are introduced from within the team. Teams introduce additional processes according to the challenges that they face. All process changes are therefore bottom-up rather than top-down.

I'll talk more about this when discussing reflective improvement.

This post is a part of the selected archive.

Out of town

I'll be out of town for the next two weeks, so I won't be blogging till I get back.

I'll continue posts on Crystal Clear when I get back.

Tuesday, May 24, 2005

Crystal Clear - Frequent Delivery

Crystal Clear is a lightweight agile process primarily intended for small teams (< 10 people) and projects which are not life critical - you wouldn't use this to control a nuclear reactor or to send a man to the moon. Unlike most other rules heavy processes, there are only three "rules" in Crystal:
  1. Frequent Delivery
  2. Osmotic Communication
  3. Reflective Improvement

Frequent Delivery

Crystal Clear is based on the premise that the ultimate success of any software is to have a satisfied customer. This may be what is written in the specification but more often than not, it is different from the specification. When the customer embarks on a project, they themselves are not exactly clear as to what is possible by the software. As the software is developed, they get a clearer picture of the software and usually have some changes to how the software operates.

Traditional (non-agile) processes place a great deal of emphasis on having a detailed specification which is agreed upon at the beginning and signed off by both parties. When the software is finally delivered, the customer often finds that the software doesn't do what they had in mind, while the developers point to the spec and show how everything that was agreed upon has been implemented. Making changes at this point could cause massive redesigns, but at the same time the customer is not happy with the product. Neither side is willing to move, with the result that the software is ultimately a failure.

Crystal Clear emphasises frequent delivery instead. Deliver working software to the customer every few weeks. This has two major advantages. One, the customer has some working software with periodic updates. This keeps up the customer's confidence high that progress is happening. It also gives the customer visibility into the project and enables them to keep track of the progress. Secondly, it gives them the opportunity to use the software and come back with feedback. This feedback is easier to incorporate because the software is still in development.

Another advantage of frequent delivery is that it also gives confidence to the developers that the project is moving forward. It builds morale when you see new features in the hands of the customer every few weeks. There is nothing as draining to developer morale as long projects with no end in sight.

Delivery cycles in Crystal Clear are around 3 weeks to a couple of months in duration. During a delivery cycle, you pick the features, implement, integrate and test them and then pass it on to the customer. The actual duration of the delivery cycle depends upon the project. The delivery cycle should give enough time to implement, integrate and test a few features. Apart from that, shorter delivery cycles mean quicker feedback from the customer.

Thats it for frequent delivery. I'll cover osmotic communication and reflective improvement next.

This post is a part of the selected archive.

Monday, May 23, 2005 bookmark this

I just saw this post on the blog on how you can add a Bookmark This link for each post. I've added it to my blog here. Now, if you want to bookmark a particular post, you can just click on the Bookmark This link and add it to your list. Pretty cool! I use to keep track of my bookmarks and it would be awesome if other sites also had something like this.

Saturday, May 21, 2005

Processes in a small company

Remember Agile India 2005? One of the reasons I had attended it was because my company was interested in introducing some processes. Gaurav's post woke me up and reminded me to write about my experiences with them.

The final outcome was that my team (7 people) adopted the Crystal Clear process. This is a relatively less known process compared to Waterfall, Spiral or XP. I'll be writing more on Crystal Clear, and why we chose it in the next few days. In the meantime, check out the Crystal Clear website.

Conversational Blogging

Dina has a good blog post titled Conversational Blogging. In it she says "I find I am so let down when I read a post without comments".

There has been a lot of discussion about what make a blog. Is it the personal voice, or is it that readers can add comments? Or is it about linking to other posts?

The first thing to realise is that it doesn't really matter whether your blog is really a blog or not. The only thing that really matters is that you have some interesent in posting and your readers have some interest in reading it. Whether you call it a blog or a frequently updated website is really irrelevant.

That said, how do I identify a site as a blog rather than a website? For me, I agree with this post by Amit that the main thing is the distinctive voice of the writer. But all this is just to name the page as a blog or website, which like I stated above is really quite irrelevant. If the page is compelling, it doesn't really matter whether you call it a blog or not.

Now, coming back to the comments part. Some blogs don't really need comments. This is especially true of link blogs which just provide links or reproduce other posts with maybe a small commentary. However, blogs with essay type posts greatly benefit from having comments open.

Very often I've encountered posts that I would like to have commented on but the comments are off and I can't really get down to crafting out an email. What's more, I can't see what everyone else thinks about it either. The result is that there is no real conversation. The flip side is comment spam/trolls. Its irritating for sure. Blogger doesn't have any good method of preventing comment spam, but if you're hosting your own blog there are some solutions to it.

So comments are definately needed if you are into the whole "blogging is conversation" idea. If you are not into it, then you can get by without comments. I definately think that the power of blogging is the conversations that it generates, and therefore have my comments on, but if you don't believe so then thats fine too.

Here is a small example to show what I mean. Read Amit's original post, and then read this cross-posted version with comments enabled (read the comments too). Which one is more enriching? My vote goes for the version with comments.

Monday, May 16, 2005

Future of corporate blogging?

eWeek has this cartoon on corporate blogging. While its meant to be a bit funny, I can see the day when something like this actually happens.

Friday, May 06, 2005

Fixed vs Liquid reopened

Matt Linderman at Signal vs Noise reopens the fixed vs liquid debate. Check out the comments too.

The main reason for most websites not adopting liquid layout is line length readability. I changed my site layout a few months ago from fixed (which was the blogger default) to liquid.

At 800x600 and 1024x768 it gives about 10-15 words per line, which is about optimum for reading. Higher resolutions can cause the main text width to get too big to be easily readable. This can be solved by using the CSS max-width property, but I've not implemented it yet.

Another advantage is in accesibility. When the user changes the font size, the layout remains consistent without text overflowing from one column into another.

Another reason, which is specific to my site layout is that it gives more space for the photo thumbnails at the top of the page. At 1024x768 it spaces out the thumbnails nicely with a pleasing margin at the sides. In the previous design, they were restricted to about 760 pixels of width leading to some amount of cramping. The flip side is that they now take two rows at 800x600.

Fixed width designs can be good in situations where there are a lot of fixed width elements in the design (images etc). They are also good when designers need control of the design to maintain some identity. The main problem with liquid designs, the line length readability issue can be solved with the max-width property.

Otherwise I feel more people should give liquid layouts a try. If it doesn't work, it can always be thrown away, but the sad part is that most people don't even try it, prefering instead to copy a fixed width design from somewhere because everyone else is doing it.

Sunday, April 10, 2005

Phishing fun with Unicode

Remember the phishing attack I had posted about before ? IE was immune to the attack because they hadn't implemented the unicode support for domain names. Well, Ned Batchelder posts about this amazing new Unicode phishing attack, which works on IE, but not on Firefox, the reason being Firefox's incomplete support for bidirectional text rendering.

Here is the link: Phishing fun with Unicode

Basically what the attack does is to get past spam filters by writing certain sequences of text in left to right rendering mode and certain sequences in right to left rendering mode. Since IE has good support for bidirectional text rendering, the text is properly rendered, and it fools spam filters that do not understand unicode. Very clever.

A similar attack which would work on both IE and Firefox can probably be achieved (I've not tested this) by inserting zero-width spaces (U+200B) in between letters of a word. Filters that do byte by byte string compares would not match, but because this character is not rendered, it would look like a normal word to the end user.

Monday, March 21, 2005

Bangalore Python meetup

I attended the third Bangalore Python meetup. It was my first time there, having learnt about this group only recently. The meeting was great. Around 19 people attended the meetup. After the initial introductions, I started out with a talk on Beautiful Soup. Beautiful Soup is a Python module that is just perfect for screen scraping applications. The website has more on this module. After that we had a Birds of a Feather (BoF) session to discuss a Perl CPAN like module for Python. Anand has posted the minutes of the meeting, and Swaroop has another overview, along with some pictures.

Saturday, March 19, 2005

IE Shines On Broken Code

Don't know how I missed this. An article on slashdot posted on 19 Oct 2004 claims that IE Shines On Broken Code. It says,

Basically, the story is that Michael Zalewski started feeding randomly malformed HTML into Microsoft Internet Explorer, Mozilla, Opera, Lynx, and Links and watching what happened. Bottom line: All browsers but Microsoft Internet Explorer kept crashing on a regular basis due to NULL pointer references, memory corruption, buffer overflows, sometimes memory exhaustion; taking several minutes on average to encounter a tag they couldn't parse.

Friday, March 18, 2005

Jolt Award Winners

SD Magazine announced the winners of the 15th Annual Jolt Product Excellence & Productivity Awards. Winners include Subversion, Eclipse 3.0, FogBugZ and Head First Design Patterns. Joel on Software (the book) also won a Jolt Productivity award. The first link has the entire list of Jolt and Productivity award winners.

Thursday, March 17, 2005


BangPypers is a Yahoo group of Python programmers in Bangalore. It was created only recenlty, and provides a good forum for discussing Python If you are in Bangalore (or even if you aren't), and are interested in the Python programming language, then think about joining it. One warning: The group is sometimes spammed with job postings for python programmers, so you may not want to join with your favourite email address. Use a rarely used email address instead.

Wednesday, March 16, 2005

Billionaire club

Gaurav Bhatnagar writes about a couple of interesting statistics, which covers the good and the bad. Quoting,

  1. India has 8th most number of billionaires in the world - 12 in all
  2. The average Indian billionaire's wealth is equivalent to almost 9 million times the country's per capita GDP. That is an astounding number and highlights the disparity of income in our country.

An excellent article on a related topic is this post by Dilip D'Souza. He says,

Nobody need grudge the Mittals and Premjis their riches. But while we applaud them, while we luxuriate in knowing that there may finally be a climate in India where acumen and entrepreneurship get their due, we might spare a thought for the running men around us, for the poverty that is still so evident in this country.

Tuesday, March 15, 2005

Pi Day

Some random trivia: Yesterday was Pi Day. Quoting from the wikipedia article,

March 14, written 3/14 in the USA date format, is the official day for Pi Day derived from the common three-digit approximation for the number π: 3.14. It is usually celebrated at 1:59 PM (in recognition of the six-digit approximation: 3.14159). Some, using a twenty-four-hour clock rather than a twelve hour clock, say that 1:59 PM is actually 13:59 and celebrate it at 1:59 AM instead. Parties have been held by mathematics departments of various schools around the world.

Saturday, March 12, 2005

Blogs of some others who attended Agile India 2005

Here are links to blogs of people I met/saw/listened to at Agile India.

Agile India - Ravi Mohan

One of the talks I attended was given by Ravi Mohan. Ravi described his experiences in applying Agile methodologies (XP in particular) to his project.

To start with, the project is not your typical everyday project. The project is in the AI domain, and is implemented in a combination of Lisp, Erlang and C, with Ruby as the glue between the three. The whole thing runs on a cluster of around 200 unix boxes with a parallel virtual machine layer above it. The entire project had a team size of one (Ravi himself).

Given a project like this, is it possible to apply agile methodologies to it?

The conclusion was that it is possible to apply some of the practices, but some of them crashed and burned. For instance, XP says that the customer should always be available to give feedback. That was impossible here. Another problem was getting unit testing tools for code in Lisp and Erlang. Yet another problem was that some functions were probabilistic in nature (for eg. return true 90% of the time), so if it gave the wrong output, it was often unclear whether it was because of a bug or because it was in the 10% when it was supposed to give another output.

Other practices like breaking up the requirements into stories worked very well. Continuous integration was another big success.

Overall, XP kindof worked, but not without heavy modification of the process (is it still XP then?).

Friday, March 11, 2005

Who's on First?

[via Ned Batchelder]: Check out this amazingly funny dialog between a cashier and a customer at a video rental store: Who's on First?

Thursday, March 10, 2005

Agile India - Bret Pettichord

First up on Day 1 was Bret Pettichord's keynote address. He spoke about Agile Testing. The question being answered was how agile methods redefine the role of QA for a project.

Traditional QA has mostly been about testing (finding bugs) and, in some companies, enforcing processes and methodologies. Agile methodologies however, view the role of QA as one of customer satisfaction. In order to fulfil this goal, the software is constantly exposed to a number of "reality checks". These checks are writing unit tests before coding, continuous integration, short release cycles to get customer feedback and continuous acceptance testing. These checks happen often during the course of the project.

The difference between agile QA is that in agile QA is a continuous process from start to end, whereas in traditional models QA is often seen as a phase at the end of the project (because of the framing of QA as testing/ process enforcing). Agile methods also say that everyone is involved in QA from developer to project manager to testing teams, while traditional models have a seperate QA team responsible for ensuring quality (does this mean that developers or managers are not responsible for ensuring quality? Is it okay if developers write sloppy code or managers rush through a project?).

To summarize, in agile teams, QA is everyones responsibility and continuous reality checks are done throughout the lifecycle to ensure that the customers are getting what they actually want.

Tuesday, March 08, 2005

On Lisp

I only found out now that Paul Graham's Lisp book On Lisp is available for download from his site. What are you waiting for? Go download it.

Monday, March 07, 2005

Specialization is for insects

From Henry Jacob:

"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly.

Specialization is for insects."

- Robert A. Heinlein, Time Enough for Love, 1973

By the way, Henry was one of the speakers at Agile India 2005 and works as an interaction designer.

This post is a part of the selected archive.

Back from Agile India

I was out attending Agile India 2005 this weekend. In short, it was awesome. Got to attend some good sessions, and more importantly, meet lots of interesting people. I got to put out a work of thanks to the organisers who did a pretty awesome job of running everything smoothly. Usually something or the other goes wrong, but not this time.

I need a few days to collect and summarise my notes and then I'll post a more detailed account of the conference.

Thursday, March 03, 2005

Bill Gates to get knighted

Reuters reports that Bill Gates will be getting an honorary knighthood. Usually, only citizens of the Commonwealth get knighted, so this is a rare event. However, he won't be entitled to add the "Sir" in front of his name as that honor is reserved for citizens of the Commonwealth.

Thought Google Maps was the first to come out with interactive maps? Check out Its maps the whole of switzerland and provides dynamic zoom and resize, and apparantly was around long before Google Maps.

Tuesday, March 01, 2005

Yahoo! Web Services

[via Ryan Tomakyo] Yahoo! has jumped onto the web services bandwagon with Yahoo! Web Services. In another telling blow to the SOAP camp, Yahoo went ahead with a REST based architecture [In REST, you use URIs to access resources rather than complex XML messages - Click here for a good introduction]. I wouldn't be surprised to see SOAP dying a slow death over the next few years.

Monday, February 28, 2005

Friday, February 25, 2005

Has Yahoo! purchased Flickr ?

Niall Kennedy: Rumor: Yahoo! has purchased Flickr

With bloglines being bought by Ask Jeeves and Flickr being bought by Yahoo, thats two of my favourite and most used web apps being bought out. Looks like this is the big year for web applications. Whats next? Google buying out

Thursday, February 24, 2005

Location changed

I've changed my location on the About Me panel to Bangalore. No point having it to Singapore when I've been in Bangalore for the past few months. I'll change it back to Singapore when I return.

Agile India 2005

Agile India 2005 is being held in Bangalore next week. This is a conference you don't want to miss if you are in Bangalore. Registration is only Rs.500 per person for a pretty impressive speaker list. Normally these types of conferences cost many thousands of rupees. Don't miss it.

Wednesday, February 16, 2005

Microsoft Shows its Security Seriousness

From Joe Wilcox: Microsoft Monitor: Microsoft Shows its Security Seriousness.

These are some pretty mindblowing announcements from Microsoft. One thing you can't accuse MS is of sleeping. Obviously they have targetted security in a really big way. I like the idea of releasing IE7 early. And Microsoft venturing into antivirus software? Sounds good, but this is an entirely new direction for them, so we need to wait and see how well they do here. I'm sure this announcement has given all the anti virus companies a bit of heartache.

Tuesday, February 15, 2005

Rediff interview with NASSCOM president, Kiran Karnik

Rediff has in interesting interview with NASSCOM president, Kiran Karnik. One good thing about the interview is that he cuts away at all the hype and gets down to the core of the industry. Quoting:

"Indians are merely going for software programming: it is like a car mechanic repairing cars, which is a tremendous ability. But while we can repair cars, we cannot design them! We are merely roadside mechanics," says Karnik

Friday, February 11, 2005

Carly's Gone. HP Celebrates.

[via Joanna Rothman] A stinging article on Carly's time at HP: Carly's Gone. HP Celebrates. It's kind of sad really. A once great company, now struggling for its very survival. Quoting from the article:

In the midst of the revelry, excited employees openly talked of their frustrations with Fiorina's management style, which seemed to place Wall Street expectations ahead of nose-to-the-grindstone innovation, the very bedrock upon which HP was built. This is, after all, the company that is credited with developing the first personal computer in 1968, a string of scientific calculators, and the desktop ink jet and laser printers.

Fiorina's obsession with Wall Street pushed much innovation to the side, and eventually led to a rather unsettling change in the HP work environment: the company's very first layoffs. When it was all said and done, 15,000 of the then 85,000 workers found themselves without a job by the end of 2003.

Update: Red Herring wrote an open letter to Carly Fiorina in January 2002. Here it is.

Scoble talks to Mark Jens

Scoble talks to Mark Jens, the fired Google blogger. My previous post on this topic is here.

Dave Winer on CNET's new RSS reader

Dave Winer writes about CNET's new RSS reader.

One of the cool things he mentions is that by having an RSS reader, CNET can get the RSS feeds from rival tech sites and display them on its site. Readers then visit CNET to read news from other sites. Brilliant.

This is legal of course, but I'm sure the rival sites will have a thing or two to say about it. We can expect a lot of controversy over this in the upcoming months. I'm looking forward to it :-)

Update: Fixed the broken URL

Thursday, February 10, 2005

Jason Calacanis on Bloglines acquisition

[via Scoble's linkblog] Jason Calacanis blogs about the Bloglines acquisitions. Jason is the guy who owns Weblogs, Inc, which in turn runs the popular Engadget blog.

What happened to Mark Jens

It's now confirmed the Mark Jens was fired by Google. Jaremy Zawodny (of Yahoo fame) talks to Mark. Scoble will be talking to him later on.

In case you have not been following the controversy, here is a recap:

Mark Jens, an ex-Microsoft employee was hired by Google a few weeks ago. He started a blog to blog about his life in Google. In his very first post, he posted about how Google's pay package was terrible. Needless to say, big shots in Google had a talk with him and made him remove the post (Bloglines has a cache of it). Everyone then thought that it was the end of it.

Well, as it turns out, it was not the end of it. Rumours started floating yesterday that Mark had been fired from Google for his posts. And today, its been confirmed. As suspected, the reason was the posts on his blog.

Now, Mark obviously made a mistake. You can probably say things like this in Microsoft, because they are a lot more open about blogging than Google.

But firing him for it? It would have probably been enough to get him to edit the post. This is terrible PR for Google. Google has a reputation for being a highly closed and secretive company, but now it seems that they are also highly paranoid. What is worse is that the information is probably not very secret. This kind of information will leak out anyway when employees talk with their friends over dinner. By firing him, this information is going to spead so fast that everyone is going to know about it.

Worse, they went out of the way to remove all traces of Mark Jens from Google's index. Go to Google and search for "Mark Jens". His blog used to be on the first set of results. I'm stunned.

Everything could have been solved by asking Mark to edit his post. What does Google accomplish now? They just reinforce the idea that they are paranoid and secretive. This is just such bad PR for them.

This is a case where Google could learn a thing or two from Microsoft. No matter what the evils of Microsoft are, one thing is for sure: Their open blogging policy has done them a lot of good, with Scoble leading the way.

Wednesday, February 09, 2005

HP fires Carly Fiorina

Engadget reports that HP has fired Carly Fiorina. Not that this was surprising. The most recent issue of Fortune magazine has HP's troubles as the cover story and there were rumours over the last week that something like was going to happen.

Monday, February 07, 2005

New phishing attack

[via Boing Boing]

[Note: This doesn't work with IE, because IE doesn't support Unicode in domain names. The laziness of the IE team has saved them from this exploit]

First, open this page (the phished page):

Them open this page (the original):

Check the url for both. Check the link you are going to for both. Identical ? But both go to different sites.

For an explanation, click here.

Bloglines bought by Ask Jeeves

The hot news going round the blogosphere is that Ask Jeeves has bought Bloglines. I LOVE bloglines. I'm hoping that Ask Jeeves doesn't screw it up.

Friday, February 04, 2005

Enhancing Internal Communications

Nick Fink has put online a presentation titled "Enhancing Internal Communications with Blogs, Wikis, and More". One of the interesting things is that they show how blogs and wikis are used in companies like Google (its called goowiki :D).

Also check the resources slide at the end for some useful links.


If you are wondering why this blog is called "~" (tilde), the reason is because ~ denotes the home directory on unix systems. The name has caused a fair amount of confusion, and I'm thinking of changing it.

Thursday, February 03, 2005

One year old

On 30th Jan, this blog became a year old. Wow, has it been so long already? Anyway, its time to celebrate. First, thanks to Raul for getting me started on this one year ago.

Anyway, I was going through some of my old sites, when I came across my old journal site (its still up!!) where I posted (sporadically) from December 2000 up to mid 2002. It feels kind of lame now. I guess you can call it a blog, though blog was not a recognized word then. I'm getting old ("Son, back in my time there were no blogs. We manually edited HTML in notepad and FTP'd it to the server on VSNL's dial up connections.").

Also, the site for the company I used to run with my friends way back in 1998 and 1999 has been archived by the wayback machine over here. Its kind of funny, in 1998 we had these pathetic Internet connections. Anyway, someone from Singapore wanted to get a website designed for some real estate project and they found us through our website. They had no idea we were college students of course. One day, on returning from college, we found these three guys at my home (they had no idea we were college students), and we were showing them our stuff over this pathetic 9600 baud Internet connection. When they asked why it was so slow, we made up something like "We optimise your site so much that its accessible for people on 9600 and this is to test that". lol. Needless to say, we never got that project.

Wednesday, February 02, 2005

Google ignores web standards

The index page of the blog is now XHTML 1.0 Strict compliant.

It would be CSS2 compliant as well, except for the CSS added by blogger to get that blogger bar to appear on the top. Same thing for comments pages, where some html dynamically added by blogger breaks the standard. This sucks.

An addendum: You would think that at least Google's homepage would contain valid markup, but no. It's not even HTML 4.01 Transitional compliant, leave alone XHTML 1.0 Strict. The page is so minimal, with only a seach box, a couple of lines of text and a few images, and they can't even get that to comply. Pathetic.

This is a perfect example of example of where Postel's law (be conservative in what you send, liberal in what you accept) breaks down. It is only because browsers are so liberal that no one cares to make their website standards compliant, and this hurts interoperability in the long run (RFC 3117, Section 4.5 Robustness)

Time to take action?

Seth Godin put out a list of what he thinks were his best posts of 2004. My favourite is "Time to take action?".

The thing is, we still live in a world that's filled with opportunity. In fact, we have more than an opportunity -- we have an obligation. An obligation to spend our time doing great things. To find ideas that matter and to share them. To push ourselves and the people around us to demonstrate gratitude, insight, and inspiration. To take risks and to make the world better by being amazing.

Sunday, January 30, 2005

New template

I've made some changes to the template.
  • The layout is now fluid, which means that it should occupy the entire screen. Try resizing your browser window to see how the layout is affected.
  • I've also changed the colours to a standard black and white to make it easier to read.
  • Link colours are back to default - blue for unvisited links and red for visited links.
  • The page structure and CSS layout has been made way simpler. If you did view source on the previous version and on this version, you would see the difference.
  • The layout is specified in percentages of the font size, so if the font size is higher, the margins etc will be more and so on. For those running high resolution displays: Try increasing the font size to make it more readable (ctrl + in Firefox). For those on super low res displays, you can reduce the font size. If my calculation is correct, the layout should still be propotional even with the changed font size. I'm planning to add in some Javascript + CSS later that will allow you to click a button to change the font size.

Blog template

I'm looking at changing the site layout. I will probably keep the colours, but I want to get rid of all the blank space on the sides. At the same time, it should be flexible so that the layout is not hardwired to a particular screen resolution. If you have any ideas, post them in the comments.

Podcasting: Digital pirate radio

Podcasting. After months of waiting and looking and waiting some more [mainly because of the firewall at work], I've finally decided to listen to podcasting.

Podcasting is the pirate radio of the digital age and are to radio what blogs are to journalism. It is actually nothing more than using RSS to deliver MP3 files to your subscribers. But it wouldn't be half as cool if that's all it did. Podcasting software like iPodder not only download the RSS feed, but dowload the enclosed MP3 files and automatically transfer them to your iPod (or any other player). So you dump your iPod to your PC at night, set iPodder to download feeds while you sleep, and when you wake the next day the latest files are sitting on your iPod, ready to be listened to during your commute to work.

Friday, January 28, 2005

The VW ad spoof

via Gapingvoid: Jeff writes about the spoofed VW ad.

You are no longer in control of your message, advertisers. You can fight it or you can embrace it.

Learn the lesson from the music industry. They fought. They lost. Big media is trying to learn that lesson now. TV is trying to learn that lesson. Your turn, advertisers.

The ad shows a suicide bomber in a VW who tries to explode himself, but nothing happens to the car, followed by the tagline "Small but tough". VW is threatening to sue for the damage caused to them.

Hugh, of gapingvoid, talks more about the changing dynamic of advertising in The Hughtrain, which in turn is based on The Cluetrain Manifesto.

Copying music onto iPods

I just came across this comment on Dilip's blog. She brings up an excellent point. There are many people who would never copy in an exam or plagiarise their academic thesis, but have no qualms about copying copyrighted music onto their iPods. Why?

This is an interesting question, and worth a much more detailed reply. The difference lies in the evolution of online culture compared to offline culture. The Internet has historically been a medium for the open distribution of information. Most Internet users have been brought up in such a community, and thus most Internet users show a distinct leftist bias (at least as far as IP is concerned) in their views.

The general view has been that once you buy a CD, it is yours to do whatever you want with it. If you want to copy it and distribute it for free, then that's your choice. In reality, you don't buy a copy of the song, only a license to use it for personal use, and under the license, copying and distributing is illegal.

There has been a lot of controversy regarding these licenses. After all, you never sign one when buying a music CD, and even licenses for software products have been mired in all sorts of controversy regarding their legality. It surprises a lot of people when they realise that they don't actually "own" the music CD or software that they bought. Software EULAs in particular add all sorts of absurd conditions in legal jargon that no one has a hope of understanding. Many are surprised to hear that common license agreements prohibit resale of the software, even if you paid for an original copy. Music CD's are even worse, with most people never even seeing the license which is printed in fine print in some corner of the CD or cover.

Intellectual property evolved in the 18th century out of a need to give creators limited monopoly over their creations in order to spur creativity. The reasoning is that if creators have no incentive to create, society as a whole would be poorer for it. The concept is to promote creativity in society, and protecting the rights of the creator is the means to do this, not the goal.

Today, IP is being used (abused?) to squash other creators, and is therefore not serving its original purpose - indeed hindering the purpose - of promoting creativity in society. This is the root cause, the reason why many people are against current IP laws. They feel that they are unfair, and no longer serve their original purpose. They are against organisations like the MPAA and RIAA that seek to use IP solely to enhance their bottom line. They feel that the laws are too restrictive and must be modified or an alternative found (Some are promoting creative commons, which is much less restrictive than all rights reserved, but still protects the creator, as the alternative).

Prominent online blogs and personalities are encouraging people to copy music and movies. They promote the view that if you bought it, then it ought to be yours and you should be allowed to do what you want with it. The unfortunate thing is that many users nowdays don't really realise all this. They just see their friends do it and think that it must be okay. Oh well.

Some references -
  • Larry Lessig is a prominent IP professor and lawyer at Stanford Law School, and he is the creator of the Creative Commons. He has written numerous books on these topics.
  • The November 2004 copy of the prominent WIRED magazine is titled "Fight for your right to copy". A free online copy is available here.
  • The Slashdot - Your rights online section is extremely widely read.
  • The Electronic Freedom Foundation is a huge, well funded non-profit for the protection of digital rights.

Wednesday, January 26, 2005

Funny Mappoint bug

via Scoble: Want to know how to go from Haugesund, Norway to Trondheim, Norway? Mappoint shows you how
Dave Winer points to a post by John Robb that explains a common fallacy promoted by the press. Quoting,

I am nonplused by the language, "fierce attacks in Iraq occurred in the run-up to the elections." This implies that fierce attacks will end with the elections or that the elections are the primary cause of the violence. The trend lines belie this. Only the targets have changed and not the volume, ferocity, or sophistication of the attacks.


My blogroll is up to a hundred feeds now. I've now removed the blogroll listing from the sidebar on the right, and replaced it with a link which goes to the complete listing at bloglines.

Monday, January 24, 2005


via Scoble's linkblog:"Committees don't have vision. Committees have meetings"

That's funny, only because we all know that it's so true. The rest of the post is pretty good too.

BBC gets on the podcasting bandwagon

via Dave Winer: BBC Radio has started a podcast for its sports program Fighting Talk. This is a very pleasant surprise. Podcasting is still a very new technology, largely confined to technical users. It's great to see someone like the BBC embracing it.