SL vs India - 2009: Review

After reading some heated comments by others I thought I'll jot down my thoughts as well.

Firstly, everyone needs to remember that after all said and done this is still just a game. Every team has their moments. In this particular series India outplayed Sri Lanka in all departments. A harsh reality check for Sri Lanka who came into the series with high expectations. True, the wickets weren't ideal for test cricket, but India handled them better (home advantage and all that jazz).

I'm not trying to run down Sri Lanka, far from it really. Just a recap of what I saw. Fortune favours the brave - and Sri Lanka certainly weren't brave from what I witnessed: defensive fields were set throughout and other than substantial contributions from Dilshan, Mahela and Paranavitana there wasn't a standout knock to motivate the other players (something like what Shewag did - basically grab the game from the opposition).

Sri Lanka however, will take heart that they did learn a lot from this series and will surely bounce back stronger in the next.
1. The performance of Paranavitana at the top - This young man is looking solid and is a good investment for the future. Dilshan with his usual explosiveness. Mahela did play well in the first game and signs that Sanga is coming back to his best. From the bowling perspective, the only bright spark was Herath. He seems to have found his confidence and persistence and is consistently getting wickets which is pleasant to see.
2. One important lesson learnt should be that going into a test match with just one front line fast bowler will just not cut it. Sri Lanka seem to do this time and time again. It never works! Its time to forget this and play the game. My take is this, if two quality spinners aren't going to cut it then definitely three aren't going to make a difference. Test cricket is all about variety and options. Out thinking your opponent, and to do that you have to have the weapons.
3. Another lession: Attack! When you have a new batsman at the crease attack him. No matter how good he is, he still has to take guard, get his eye in, ascertain the bowling before he plays his shots. The chance is always there for him to make a mistake. So attack! From what I saw, Sri Lanka lacked that.

Having said that, They are obviously a work in progress. Getting to number 2 in the world is not a small achievement. Its the result of consistent performances throughout and for that the captains, both Mahela (previously) and now Sanga are to be thanked.

Finally, Murali is certainly not a spent force. He's still the best - Everyone has opinions, but numbers don't lie. Unfortunately this series wasn't kind to him.

http://bit.ly/76yBZq

The google story

The Google Story from Nick Scott Studio on Vimeo.

What is Google Chrome OS?

Economic Meltdown...

http://www.phdcomics.com/comics/archive.php?comicid=1077

Mint techcrunch presentation - 2007

Techcrunch50 winner 2007. Intuit has now put in an offer to buy them for 170M. Very impressive growth.

Completing the Job

Why do people like to do the bare minimum and be satisfied? Its going to come back eventually and you're going to have to finish what you started! Why not complete it in one shot?

I have to say that I am speaking from a technical view point. This is something I have observed recently. We're in the maintenance phase of our project and our developers have quite a number of defects to fix. In the first place, I seriously dislike having defects under my name :) But thats just me I guess. I like to test out my code as much as I can so that there are very few defects in my name. I guess its a pride thing.

So coming back to the team, I've noticed that most developers tend to fix the defect stated in the defect tracking system (ok, nothings wrong with that) and they re-test the fix for the specified scenario only. So what happens if the fix breaks something else? They wait around for our QA friends to log another defect, and the cycle continues. Why cant they test out all scenarios and be personally satisfied that - yea! I've done a good job.

Potential reasons as to why this happens,

1. They are just too busy and are overloaded that they don't have time to test every scenario out. - Ok acceptable I guess... Its the management's fault in not managing their time better and creating an environment such that they can do the best they can.

2. Poor attitude - Ok I've fixed that defect. I'm done for now, I'm outta here!

How do we correct this?

- Ensure that defect fixes are not rushed! This is very important. If the team are pressurized into fixing n number of defects per day, then ofcourse we're going to wind up with this situation.

- Maybe ensure that we have automated test execution setup. So that we execute a sufficient amount of tests (junit and selenium tests) that ensure that the project is in a stable state. So once the developer checks in the code, the automated tests run and we're ensured that at least 60_75% test coverage has been executed. This will simplify the developers job too -> facilitates the environment being more stable-> simplifies the QA's job where they need to focus on complex scenario's and edge cases. Win-win situation.

Building software systems

Ok, so the art of software architecture is relatively new compared to building architecture, vehicle architecture and other sciences that have been around for a while. They have matured such that there are a set of best practices that govern them so that its very difficult to go wrong. After all how many times do we hear of building collapses and a vehicle construction gone horribly wrong? Very rarely right?

So the good thing here is that software architecture can learn from these other disciplines. We don't have to make the same mistakes the ancient building and vehicle architects made while they learnt their trade. Of course I'm talking from a principle point of view.

Unfortunately, most software development teams seem to forget this. There are plenty of real world success story examples out there that we can draw from, but unfortunately we seem to have blinders on. The most significant example I think is this,

- Before building anything (a large sky scraper for instance, or even our little two storied house) the first thing thats done is that a solid foundation is laid - for a vehicle its the chassis. Once the foundation is complete, only then do they construct each layer, and its a layered approach, one floor at a time.

SW: We do have similar qualities here, but how often have teams forgotten the importance of laying the right foundation. How often have teams started construction of a huge project on work in progress framework code? And what does this result in? several iterations cause there are soo many flaws in the system - while the framework is being refined the final product is also being adjusted and re-adjusted. Project managers may think that starting early will be advantegous, but instead the net result is that there are soo many defects and overall instability resulting in many more iterations to fix them resulting in the project taking even longer. Too many moving parts in my opinion does not constitute to a stable release.

The well established software giants do this right, but soo many of the smaller software houses keep making the same mistake. By making this mistake once, they learn the invaluable lesson of how NOT to do things in the future right? :) but alas I've seen the same people making the same mistakes over and over again.

Google Wave

"Do something awesome" - Twitter Co-Founder

IPhone 3.0 Guide...

The iPhone 3.0 OS release promises some really cool and long awaited features
- Copy, cut and paste
- Landscape keyboard,
- Notes sync
- Peer to peer connectivity
- controlling peripherals
- Push notification

Just to name a few.
Read on here - i.gizmodo
and here - AppleInsider

Credit Crisis - Explained

The Crisis of Credit Visualized from Jonathan Jarvis on Vimeo.

Revolutionary New IPod

Check out the link - http://www.apple.com/ipodshuffle/

Leadership is not management....

Something very interesting I came across...

"Management is about manipulating resources to get a known job done,..leadership is about creating a change that you believe in.

Movement have leaders and movement makes things happen. Leaders have followers Managers have employees. Managers makes widgets. Leaders make change."

Read on here...
Nati Shalom's blog-leadership is not managment

The worlds most admired company is also my most admired company!!

Check out the link - Apple

Safari 4 benchmarked

Image from www.cnet.co.uk
Safari 4 Benchmarked !

The Game !!

Excelling in the software industry takes more than just pure technical skills.

Recently I came across a really interesting situation. There is this engineer in my team who's techincally very gifted. Her knowledge of design patterns and their application, along with excellent coding structure and dicipline is very comforting. Even though she's relatively young, her determination to do the right thing, instead of short term gains and short cuts is refreshing. 

However, given her excellent technical ability, she prefer's to socialize with only those she deems as technically strong and highly interlect people. As a result of this she hardly socializes or even communicates with her own team members. She has no rapport with her team. She's very reluctant to offer a helping hand to team mates who are in trouble and she tends to complain and find fault in others very easily. Furthermore, her dicipline in terms of time entering and responding to emails - especially project management related is very very poor. 

This has resulted in a very tricky situation. With this economic situation, teams are very selective in who works at the client site and who should travel back and work offshore. Her position with this regard hangs in the balance. Her own team members and even the project managment team are not that keen on having her onsite as she is difficult to work with - however the client is extermely statisfied with her as her designs and code is of high quality.

Here's my take : As much as individual ability is important, the software industry is very much a team sport. You constantly work in teams, brain storm as a team and come up with a solid design together and then work in cohesion and harmony to develop the solution. Each players individuality bring different idea's - different idea's breed conflict - conflict breeds creativity. The key here is to not to lose sight of the end goal during the conflict - the end goal meaning the ultimate most suitable design. It is very easy to get carried away and play on ego's etc. But this is where maturity plays an important part.  

So to thrive in a situation like this, it is very important to develop people skills ! Cause you're constantly working with people. Here are some examples...

- You have a pretty good design - instead of surprising everyone and presenting it to the entire team basically forcing your way through which will result in everyone being on the defensive - why not share the design with a few fellow key team members first, get it reviewed by them before presenting it to the rest. This means you will already have their buy-in and hence getting it passed will be much easier. They most probably will fight your battles for you.

- You have done something really well - maybe some design, maybe some piece of code that has increased performance drastically - while basking in your glory, make sure you give credit where credit is due, maybe someone's idea or somethign someone said sparked that thought in you. Make sure you coin all those who helped you along the way to get it done and mention their names. This gives everyone a sense of pride too. They too contributed to the end goal. This will benefit in the long run, where each one feels like they really work together. An individual's glory means the team's glory !

- During times of adversity - most often during defect triages and defect reslution - the part we hate the most :D - make sure no finger pointing takes place. Its always we did this, rather than it was this person's fault. We're all human after all.

- Spend some time out of work to get to know your team, go for a beer maybe, shoot some pool, have lunch outs,  see what their interests are. Building  friendships tremendously helps getting work done. At times when you're not there, you can be sure someone will cover for you. That helps ! 

- Make sure you always satisfy your project managment team ;) ! Their needs are simple, enter time, give them periodic updates on the progress, and let them know of issues or risks early. By making their job easy and making them look good in front of their bosses and peers, they'll take care of you in case anything comes up. 

This is the game ! You gotta love it !  

Lanka Matha

http://www.facebook.com/video/video.php?v=63797605890

Session Managment

Recently my work has lead me down the path to analyze how various enterprise applications use the HttpSession object and to propose and implement a strategy that would optimize its usage. Pretty interesting right ?

So first and foremost, what should be the ideal size of an HttpSession ? IBM proposes that it should not be greater than 10K. Overall the general consensus is that we need to keep the session as small as possible.

What should we know about the http session ?

- The HttpSession shares memory with the running web applications inside the JVM heap

- There's no limitation to the size of the http session, although some application servers can limit the number of sessions.

- The objects you store in the http session often contain other objects too (nested objects). So the cumulative size of the http session includes all of the objects you store.

- Managing session is important for application  performance as well as for scalability. If one user occupies 10MB of session data, and if 100 users hit the application, then thats 10*100 MB of memory used up for session data - which most servers wont be able to handle ( the average JVM heap is around 256 - 512 MB).

This is why managing session is so important for enterprise applications.

So here's what we decided to do.

- Quite simple really. Minimise using the session :) , if we have to keep something in session, then move it to a cache (hosted seperately) and just keep the keys in session. 

- Monitor how frequently the objects in the session are used. If they are used very rarely, then it makes sense to keep them in the database and fetch them only when required.

- Monitor on average, how many sessions are used by the web application. This will give you a decent idea if the memory on the box is sufficient or if you need to upgrade OR if you need to control the number of sessions permitted for each server so that the JVM wont trash.

- Even data that needs to stored in session should be analyzed to see which fields should be declared as transient. 

- HttpSessions should be invalidated properly during logout and browser close actions. Session timeouts cause the httpsession to be destroyed automatically.

- Keep profiling the application to see if we're utilizing the session ( and other objects ) optimally.

[Performance Analysis for Java websites, Http Session Management, Http Session Best Practises]