I love my Pandora...

Pandora is the best internet Radio out there. Here's my station that has been customized to my taste. Enjoy !

Roshan's Station

I just bought my dream car !! Woohoo !!!

Lehman brothers files for bankruptcy

http://www.bloomberg.com/apps/news?pid=20601087&sid=a82CD7OMEtWM&refer=home

One of the largest investment banks in the US, Lehmen Brothers Holdings Inc filed for bankruptcy today. This spells bad news for the stock markets around the world, as many of these financial giants are finding it hard to cope with this years credit crunch. The other to succumb already are Bear Stearns and Merril Lynch.

Merrin Lynch however is expected to be bought over by BOA for something in the range of $50billion. Lehman however, were forced into liquidation as a result of Barclays Plc and BOA withdrawing their take over bid.

This is obviously going to affect other financial instituitions and individuals who relied on Lehman for financing. So expect prices to drop in the next few weeks!

Lehman Brothers was the biggest underwriter of mortage backed securities. 

Google Chrome has been launched !!

Google has adopted a neat way of explaining the concepts behind the design and construction of the browser. As always, keeping things simple and yet effective is the mantra. 

Interview questions (4)

1. Database schema design that caters to the handling of multiple real world relationships. 

2. In the event there was no Struts, how would I go about designing my own MVC model - to mimic a shopping cart application.

3. Provide a design that would search multiple search engines and provide a consolidated set of search results for a given keyword.

4. Review a piece of code.. what are the important things I should look for.

5. Write the getDepth() method of a tree. What are the approaches I can take... 

6. Write the substring method - the only available method is getChatAt(int)

7. Write a method that would reverse a string, a method that woudl reverse the words in a string

8. Write a method that would find the number of words in a given string. The same word should not be counted twice. 

9. Provide a design on how to implment the redo and undo features of paint. Provide alternate solutions and explain why they were alternate. 

Right technology.. right time...

Using the the most appropriate technology to solve a given problem is always the right thing to do. 

Unfortunately, in some instances, the technology chosen has nothing to do with whether it is the most suitable technology to solve the problem.  It is however, the result of the following,

- The most senior person in the team is most familiar with that technology

- Someone started on a POC to implement the solution on a particular technology, and the rest of the team simply continued on that path without stopping to question if it was the right way to go.

- Fear of open source -> and the inability to pay for a suitable commercial implementation -> results in creating an already existing, tried and tested framework. Talk about re-inventing the wheel.

- Lack of far thinking. Basically focusing on the here and now and not worried about future implications..

The right way to approach any problem like this is to stop and think a little. Just because everyone is jumping on the band wagon saying lets get this done, you shouldnt!

- First think, are we using the right tools to solve this problem.

- Evaluate all your options.. measure the pros vs the cons. This has always proven to be an invaluable exercise for almost any thing in software engineering.

- Based on the requirements and projections.. are you chosing the correct technology/solution.

- How about long term support... Would it be easier to hire engineers with this skill set?

- Try and avoid 're-inventing the wheel' as much as possible. Why waste time -> simple concentrate on solving business problems rather than problems that have already been solved by others. 

This will result in a more focused development envinronment that will ease your development process and provide higher quality results. 

My two cents...

Firefox 3

I just installed the RC for Firefox 3... and i love it. Here's what to look for,

1. Performance - The performance is simple awesome. The time it takes to load up my gmail is dramatically reduced... its now a matter of milliseconds.
2. Personalization
- adding of bookmarks is simplified to just a click of a star.
- the location bar now has type ahead. It shows you search matches with your bookmarks and history
3. Downloads - Resumable downloads !!

I'm sure there's more.. but this is just in the first 10 mins of use :)

Enjoy !!

The new Murali....?

Author Rob Steen talks about the newest member of the Sri Lankan team,

http://blogs.cricinfo.com/robslobs/archives/2008/04/the_new_murali.php

Tata acquires Jaguar and Land Rover....

What a disappointment.. :(

Check it out

Steve Jobs Stanford Commencement Speech 2005

Our SCRUMified Development Process

I just thought I'll jot down my thoughts and views of the scrum methodology that we're using right now.

First of all, let me say that we're not using scrum in its purest sense. The methodology we are following is more of a tailored process that is inspired by scrum and other agile methodologies.

The nature of the project, its demands, the time lines and the concept was all highly complex and to be honest quite chaotic at the beginning. We needed to bring some sort of structure to the way we were going to execute the project, especially since we needed to leverage the onsite-offshore model.

The process:
2 week sprint cycles:
- Each sprint is planned upfront, basically setting scope for what we want to achieve.
- The first week is used for requirement definition and high level design.
- The dev team used this time to fix outstanding defects, perform research and develop proof of concepts to support the design.
- The second week is used to develop the defined requirements. This development process embraces the TDD methodology where, the main idea is to get something working first, and then start refactoring and perfecting it.
- The sprint concluded with a demo

Silo development at first
- The initial sprints were all about building individual modules as silo's. They were required to be "aware" of potential integrations but weren't scoped out, and so were not coded.
- It was all about consolidating your own world. Building features and ensuring each module achieved the required functionality

Bringing it all together at the end
- The latter sprints were focused around identifying all integration points and trying to put together these silo modules.

QA on the go
- The QA process kicks off at the end of each sprint. They test and log defects and issues against the previous sprint's code base.
- These defects are triaged and handled in subsequent sprints.
- This QA process is more like a continuous testing process - close to the continuous integration that agile promotes.

Here's my take on what worked and what didn't.

Pros
1. Iterative development: building functionality
- This definitely helped in terms of conquering the highly complex requirements. We were able to break down each requirement into manageable chunks and then take it chunk by chunk.

2. Quick cycles
This enabled the higher management and the dev team actually visualize what we were building. It also ensured that we didn't get lost and stray too far off the project direction.

3. Dependency and milestone documents
From the very beginning we maintained a dependency tracking document complete with milestones. This ensured that any dependency talked about was documented.
It also helped us track when a particular dependency will be available for integration.

Cons
1. Big picture
We lacked a big picture document. Even though there was an architecture document, it didn't really cover the big picture - how all the components "really" integrate with each other, what were the contracts, the entire business flow. I created a document that covered all the interactions and integration points with other modules for my module, but we lacked an overall document.
Due to this limitation, most of us relied on a "project champion", a single person who had the entire vision of the project. This was a huge bottleneck.

2. Iterative development: Rework
Even though this was a pro, I'm also listing this down as a con simply because of the amount of re-work we had to do. Re-work is alright, but when you have such tight deadlines to meet, the re-work should have been avoided.
What really happened was that when a feature was developed and demoed, the business most often came back and proposed changes to it. This is because, they finally were able to visualize what has been in their heads all this time, and they discover improvement points - Fair enough.

What we could have done to alleviate this situation is,
- First create paper prototypes or dummy html prototypes so that the business could visualize the application
- Only when the business has spent a decent amount of time reviewing and improving the look and feel and process flow should the development start.
(Notes for the future :P)
- Alternatively, if the UI and process flow have been signed off by the business, then all changes and enhancements should be considered as change requests and should be handled by the change request process.

3. Documentation
This is what suffered the most. I believe due to the shortness of the sprints we didn't have enough time to produce quality documentation. And this is definitely going to bite us later on, especially during maintenance.

4. Planning
Another drawback of this entire process, and the primary reason why the project isn't going as smoothly as it could, is because of the lack of planning time put upfront. The sprint planning was done in a very haphazard way.

5. Silo Development
Although it was a pro, this proved to be another drawback. I believe that we should have first developed a small prototype, complete with integrations (at some level) so that the basic framework was in place. All additional functionality could have been built on top of this framework.

Superbowl XLII

Patriots all the way.. woohoo.... !!!!

http://myspacetv.com/index.cfm?fuseaction=vids.individual&videoid=26894752

A view on onsite-offshore development...

The onsite-offshore development model is currently the cheaper, faster way to produce software. But at what cost...

Having experienced this over the last 7+ years, here's my take on it.

1. Estimation - There needs to be a very good estimation model in place. Without this, both teams (onsite and offshore) will be fighting a losing battle. The teams will be working against the clock, they WILL cut corners to meet deadlines. Code quality is compromised. More errors are introduced.
All these result in a longer testing and defect fixing cycle. The net result- the project goes over budget, and deadlines are missed.


2. Scope - This goes hand-in-hand with estimation. It is very important to only take on what you can chew. Most often, the onsite management are delusioned that the offshore team have more time and hence try to absorb scope. This too has the same result as a poor estimation.

3. Responsibility - It is extremely important that both teams; onsite and offshore, share the same level of ownership and responsibility towards delivery. If the onsite team have a "the offshore team will take care of that" attitude, then again this model is not going to work. The truth of the matter is that the onsite team have more perspective towards the issue/function. They should take it upon themselves to at least provide a sample solution towards the problem so that the offshore team can complete the job. Failing to do with will result in the offshore team working towards a solution which they "think" is correct.
The norm is that the onsite team will then reject the fix, or mark it as incomplete and this results in more cycles.


4. Skill level - In my experience, it is common to get into a consulting engagement where the client uses a few technologies that are unfamiliar. Being technologists, it is our responsibility to spend a little time ramping up on these technologies such that we are at a decent level to code and troubleshoot. Over time, it is inevitable that we will become experts in that technology. It is however important to allocate that ramp up time at the beginning of the project. True, most of the learning happens on the job. But the ground work, background reading, and the basics have to be right.
Failing to allocate that rampup time upfront will result in not being able to achieve the desired levels of productivity.

5. Communication - I don't know how this ended up so low on the list. But I can't stress enough how important communication is. Having daily sync up calls is very effective. It is important for both teams to be in constant communication so their each party knows exactly whats going on.
When i mean communication I mean,
- Daily calls
- Accompanied by an email outlining the tasks needed to be completed and a status email at the end of the day

6. Tracking - Along with communication and status updates comes tracking. This becomes an important tool to see how well you are achieving your targets and milestones. This information then feeds into your next estimation process so that you can estimate better (at least thats the idea - Learn from your previous experiences.)

Looking back, most of these are aspects of project management :). So far we've got estimation, scope and now tracking. It becomes apparent that for an onsite-offshore project to succeed, the project management has to be very good. Maybe I'm biased, the engineers and the architects are equally important but they generally take care of their business :). The bottom line is, the project management has to be pretty good to run a project smoothly.

Thoughts ??

Interview questions (3)

Here's an addition to some of the more interesting interview questions I have received during my job hunt

1. How would you write your own garbage collector ?
The crux of the question is how would you identify which objects need to be garbage collected. Here, they are trying to test your knowledge of the heap and call stack.

2. You've got an array of numbers. They are not sorted. How do you find the the first pair that sums to X (a given number)
They're looking for an optimized solution. The most obvious solution is an n^2 solution and thats not what they want...
Hint: Think about which data structure you could use.