AgileIndia 2005

Last weekend (March 4th and 5th 2005) I attended the Agile India 2005 conference in Bangalore (India). It was sponsored by ThoughtWorks and Subex Systems and all the delegates paid Rupees 500 (about 10 dollars) each. This post is on my observations and the things which I want to write about.

On the first day the Refactoring with Eclipse session was great. It basically took the video store example from The Refactoring Book and implemented all the suggested steps. I was deeply impressed by the humility and down to earth character of the conductors (Chris and Yogendra Kulkarni) even though their knowledge and experience was much more than any person's that I have seen in all the topics of Eclipse and Refactoring using Eclipse. Their application of OO technology and Design Patterns was exceptional. My brother found Owen Rogers's introductory talk on XP very informative.

On the second day the keynote by Dakshinamurthy Karra was interesting. Some points of note were:

• Certifications (like SEI CMM and ISO) can exist with XP practices as many XP practices are best practices under the certification norms.

• In XP there is no Design Phase or Design document. This means Design as a noun is not relevant in XP but Design as a verb is all pervasing. This is done through merciless refactoring.

• Pair programming reduces the cost of code reviews, training and fixing bugs.

This was followed by one of the most interesting sessions I have attended in any event: The session by Fred George. He is a very experienced guy who has been working in XP projects for more than 6 years now. In his talk he makes maximum use of humor for a strong conceptual effect. The points that I gleaned from his session were:

• XP is from JIT

• feedback identified defects

• avoid "waste"

• XP reduces staff roles and specialists

• the three corners of an Agile team are Story Team (BA + QA), Dev Team, Management(Iteration Managers)

• Selling Agile : Sell it to programmers using the fun element and the consequent constant utilization of skills. Sell it to Executives citing reduced time to market and LESS MONEY. Don't sell it to middle managers as they are risk averse.

• Its the Stories, Stupid: Delivery is paramount not process or technology

• Metrics: Count what Counts - stories, tests, never on lines of code or task cards.

• Harvest Legacy Artifacts

• Delivery focused stand-up meetings: Don't Blame - Just Fix. iteration meetings provide forums.

• When adopting Agile: Adopt all practices. "We Don't know enough(yet) to discard any of them"

• Most difficult practice: Simple Design

• Most neglected assumption: OOPs

• How do you judge individual performance: Ask the team.

I then attended the automatic codebase analysis session and the pair programming workshop. I also attended the Test First User Interfaces session by Owen. This was interesting in the context of the complex gui driven rule engine(creator) we are building in my group. Componentized testing to get complete testing of a complex gui driven application and mock-based component testing were the messages of this session for me.

Most of the presentations are available online. I felt the whole program was fantastic because of the exposure I got regarding Agile/XP and the people I got meet and interact with. The arrangements were more or less flawless and I thank the volunteers of ASCI(Agile Software Community of India) and the student volunteers for this. I hope many more such programs are organised by ASCI and other interested parties.

Dining Philosophers and XP : Part 3: The State Pattern Iteration

So I didnt do anything over this weekend. so what? i was very tired after my gym workouts. Anyway, regular readers of my blog (thanks Partha) would have noticed that i have put the source of the first iteration online for your perusing pleasure. The link is mentioned in the previous post. It is also available here.

In the next iteration I started out by implementing the State Pattern for the Philosopher Class. I introduce an abstract class called PhilosopherState to represent the different states that a philosopher can be. These are: Eating, Thinking, Waiting for Right Chopstick, Waiting for left Chopstick and Waiting for both Chopsticks. The PhilosopherState class defines a common interface for all the different states. I then flesh out the waiting states seperately as that would give complete modularization(at least I think so, but am not sure). Maybe in a future iteration I might combine them if convinced otherwise. Subclasses of PhilolosopherState are :

• PhilosopherEat
• PhilosopherThink
• PhilosopherWaitForRightCs
• PhilosopherWaitForLeftCs
• PhilosopherWaitForBothCs

I use a Table class which maintains a state object (an instance of a subclass of PhilosopherState) that represents the current state of the Philosopher. This Table class delegates all state-specific requests to the state object. Table uses its PhilosopherState subclass instance to perform operations particular to the state of the philosopher. Whenever the state of philosopher changes the Table class changes the state object it uses.

In the classic definition of terms from GoF the Context is the Table class, State maps to PhilosopherState class and the different subclasses of PhilosopherState class form the ConcreteState classes.

Now, on to avoiding deadlocks. If every philosopher never picks up one Chopstick when he can't get another one, then deadlocks can't occur. So the code includes checks to see if a philosopher can get the other chopstick before he picks up one. This is one of the simplest (albeit cumboresome and unjust) way of avoiding deadlocks.

Links to updated code will follow. I might be editing this post sometime soon to add some more developments instead of adding another post between iterations.