18 Jul 2006
If you’re in Vancouver next Thursday (July 27th), you should consider stopping by the BC Genome Sciences Centre at 6:00.
Speaker: Narayanan ‘Shiva’ Shivakumar, Founding Director of Google’s Seattle-Kirkland R&D center
Title: Google – Behind the Scenes
Abstract:
Google deals with large amounts of data and millions of users. We’ll take a behind-the-scenes look at some of the distributed systems and computing platform that power Google’s various products, and make the products scalable and reliable. .
Bio:
Narayanan Shivakumar (‘Shiva’) is a Google Distinguished Entrepreneur and the founding Director of the Google Seattle-Kirkland R&D center. Currently, he is excited about a variety of search and webcrawling technologies (including Google Sitemaps). Earlier, he was the Director of Engineering responsible for many of Google’s advertising products (including AdSense — Content, Search networks) and Google’s enterprise products (including Google Search Appliances). Before Google, he cofounded Gigabeat, an online music startup funded by Kleiner Perkins and Silicon Valley angels, later acquired by Napster. He graduated with a BS from UCLA and a PhD in Computer Science from Stanford University. His dissertation on large-scale data mining and media processing, won the 1999 Arthur Samuel Dissertation Award by the Stanford Computer Science Dept.
02 Jul 2006
Yesterday was Canada Day.
As is a usual activity on July 1st, I attended a friends bbq for a few hours yesterday afternoon. It was a pretty casual affair, I ended up driving, parking on a side street and walking down. A few hours later I walked back to my car only to see that the front driver’s side fender had been hit and the front bumper cracked and partially removed. I called the cops and explained that my car had been involved in a hit & run (albeit a minor one) but they wanted nothing to do with it, instead referring me to ICBC. After talking with ICBC, I’ve now got an appointment to see a claims adjuster in a weeks time. After that, I’ll have to make an appointment with a body repair shop.
It’s also no consolation that I’ll have to pay the insurance deductable and drive around in a smashed up VW for at least another couple weeks. I’ll post some pictures once I’ve pulled them from my camera.
A few years back I had another problem on Canada Day. I woke up early in the morning and walked out to my car only to see doors opened and a couple thousand dollars in stereo equipment stolen.
From now on I think it’ll be best if I sleep in my car every July 1st 
29 Jun 2006
We’re currently going through a bit of a development methodology change from fairly heavyweight 3-6mo releases (typically consisting of requirements, development and finally QA) to far more agile 3 week iterations.
It’s looking like each 3 week iteration will be broken down as follows: 70% development, 20% QA and 10% planning, give or take a few hours. The formal planning of each iteration will soley focus on the tasks being worked on during the roughly 2 weeks of development time. More forward-looking planning will occur outside the course of normal iterations. The 20% of QA time will be include both developers and dedicated qa persons. We’ve found that developers have a knack for uncovering problems (perhaps by their own design) that QA miss, and vice-versa, QA has much more thorough testing procedures than developers. Previously developers have been involved with QA on an as-needed basis so it’ll be interesting to see how it works out as they’re formally included in the process.
Given that our iterations are quite short, we’ve put some emphasis on developing a configuration management process that remains lightweight while encouraging frequent commits and testing without hindering the rest of the development team. We migrated from CVS to Subversion about 10 months ago and haven’t looked back since. The ability to branch in constant time was and remains a motivating factor. After reading some of Brad Appleton’s comments on parallel software development best practices, we’ve decided to start with the following branching strategy:
- The trunk remains relatively sacred (the only thing more sacred is a maintenance branch). Commits to the trunk should primarily consist of merges from iteration or maintenance branches. Rarely would there be a need to do an online commit of code that didn’t exist previously in another branch (maintenance, iteration, bug fix, etc.).
- The work of each iteration will be performed on an iteration branch.
- Each task in an iteration will be performed on a sub-branch off the primary *iteration *branch. This is to enable multiple developers from different teams to collaborate on a feature set without worry about the rest of the team. At the end of the task, the branch should be merged back into the iteration and removed. For some reason if a task does not get completed in the two weeks of development, it does not get merged down and work likely continues during subsequent iterations (although red flags should be raised if you’ve got tasks spanning iterations).
- At the end of the iteration, the branch is tagged, and merged down to the trunk and the process starts over again.
We’ve attempted to keep the amount of process-related overhead to a minimum without sacrificing quality and artifact (tasks) tracking. With any luck things will work out, and if not, the nice thing is we’ll be able to make adjustments on subsequent iterations… something that previously wasn’t easily accomplished on 6mo iterations.
Personally I’m looking forward to the change. I’ve been relatively fortunate that as a technical lead I’m primarily responsible for the technical underpinnings (items like CruiseControl, SVN, etc.) of the process rather than the planning aspects of a particular iteration or increment (set of iterations that make up a release). It’s going to be nice working on deliverables that are scoped well enough that you can get everything done in 2 or 3 weeks of development time!