About Me

My Photo
I am a Software Architect and Developer based in Bangalore, India. I have experience in building (scalable) applications using Java, JSP, JSF, JBoss Drools, Spring Framework, Hibernate, Ajax, JavaScript, MySQL, NoSQL (HBase, Project Voldemort). I am also a fan of Ruby on Rails, and have done some experimental work with it.

Sunday, October 26, 2008

Notes from Ken Schwaber presentation on Scrum

Source: Google Video Presentation by Ken Schroder on Scrum


* Everything in Scrum is time-boxed.
* It's the team which has to get things done by the end of timebox, and that should be potentially shippable.
* Scrum is about managing product development, and XP is about engineering practices for product development.
* Scrum is not a methodology, Scrum is like a simple process framework, analogous to rules of chess (which are simple, but can be used to develop complex strategies).
* Scrum brings in transparency, you know where you are and where you are heading at any given point of time.

* Product manager defines the backlog.

* Team decides the contents of a Sprint along with product manager by picking items from Product backlog.

* Sprint is somewhere between 2 to 4 weeks.
* Team should have minimum or no interupptions during the sprint.
* After the sprint, the backlog is revised and re-prioritized.

* Burndown chart as indicators for velocity gives transparent view on whether we are going to meet the marketing's deadline or not.

* Traditionally, Pressure to increase velocity can result in developers reducing the quality and/or working for long hours, and that will only result in much more slower velocity.

* More than 65% of functionality is rarely used or not used at all. Hence, product manager should select only high value items and leave out the rest from sprint. Hence, instead of trying to increase the velocity, try to re-prioritize the backlog or see if some requirements can be trimmed down.

* Architecture and design are driven through Non-functional requirements. This type of work can be done in first, second and other sprints, but all sprints much deliver business value, and should demonstrate that architecture infrastructure is working.

Saturday, October 04, 2008

Avoid using names for HTML input elements that match HTML FORM object's attribute

At work, other day we encounted a strange issue.

We have this web application which is based on Spring Web Flow, and each of the views in the flow have process buttons such as "Back", "Skip", "Cancel", and "Submit" (for main action).

In order to resolve an issue, We modified handling of Back, and Cancel buttons from using HTTP POST to use HTTP GET. In other words, instead of submitting the form to the Spring WEB Flow controller with one of the request parameter being _eventId (represented through a hidden field in form), We changed the Back and Cancel button's click handlers to use "window.location = document.forms[0].action + '&_eventId=back'" and "window.location = document.forms[0].action + '&_eventId=cancel'" respectively.

For most of the pages, this code just worked fine. However, for few pages related to certain functionality, the above code did not work. With the help of alert messages, We realized that browser was not treating document.forms[0].action as string containing action URL, but was tricked into thinking that document.forms[0].action was an object.

That behaviour seemed pretty strange as the same code was working fine for 90% of pages.

After the investigations, we found that there was an HTML input element in the page with name "action". The browser hence was returning reference to that object instead of the value of "action" URL.

This was a nice learning. And the lesson is to avoid using names for any of the HTML input elements (Input box, check box, selects, and other types of input elements) that matches the FORM object's attributes.