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.