Part 1: How am I IMPACTing following Scrum?

In a previous post in this blog, I introduced the nice little acronym IMPACT for agile. To recap, here is what IMPACT stands for -

"Iterative and Incremental development of a software by means of Merciless refactoring, Peer reviews, Automated acceptance testing, Continuous integration and of course, Test driven development"

To give you a little background around my story, let me tell you about a project that I am working since June 2006. The project is a micro-finance loan application automation server for the US financial industry. It acts as a mediator between a loan seeking customer and one of over 50 lenders in an attempt to get a loan for the customer. So, the server adds value by taking a single application to 50 odd lenders from a single submission unless no lender is left untried or some lender says 'yes' to it. This is done in real time, the processing time in average is less than 3 minutes.

Now that you have the background, let me introduce the the challenges associated with this project. The bullet points are-

• Since this involves real dollars, there is nearly no margin for an error.
• It processes more than a thousand loan applications per hour, so a high availability is a must.
• This is done following agile Scrum and each two week one/two new lending partners need to be integrated.
• The lending partners change their integration API from time to time and we need to accommodate the changes ASAP.

To address these challenges this is how we are responding-

Iterative and Incremental development (IID)

We are following Scrum and using ScrumPad to manage the IID. Basically, our clients/product owners put new requirements in terms of user stories in the product backlog at ScrumPad. So, with the prioritized product backlog we, the team, pick items to a sprint's backlog. Then as usual, we break it down to tasks and do everything that it takes to meet the deadline of two weeks. Within a sprint the following are the milestones-

Day 1	Day 2	Day 3	Day 4	Day 5	Day 6	Day 7	Day 8	Day 9	Day 10
Sprint Planning	Dev & Test	Dev & Test	Dev & Test	Dev & Test	Dev & Test	Dev & Test	Dev & Test	Test Release	Production Release

• 8th day - Sprint works are completed.
• 9th day - Test delivery at a near production environment and feedback gathering from product owner.
• 10th day - Incorporate feedbacks and release in production.

Note that, we generally produce a number of test releases within the first 8 days. That gives us an earlier chance to gather client feedbacks.

The beauty if this approach is, with this model in place we can release as early as in 8 working days, if not earlier. So, this helps us meeting the last two challenges as mentioned above.

Merciless refactoring

Developing incrementally offers much challenge in attaining the longevity of the product. Because, naturally as new features come in, we need to make room for that in the existing implementation.To ensure the quality and life of the product, we do merciless refactoring as we go. We have over 90% unit test coverage, which helps us in doing this continuous refactoring. So, the idea is-

• Writing unit test and acceptance test.
• Refactoring our code/design and validating against automated tests.

Peer reviews

This is probably the most important practice that I recommend. Because, as we had new members in the team, we found that the quality was somewhat degrading. Once, we started peer reviews, it was very helpful to the new comers as well as the veterans to keep the code quality up to the mark. We review the following things-

• Naming of variables, methods, classes, files, namespaces etc.
• Use of private methods for increased readability.
• Hard coded string literals or constants.
• Long/nested loops and long running if-else blocks.
• Code commenting.
• Quality of coding.

I would suggest you to try Microsoft's Stylecop, it will give you a great head start to ensure the first level code quality by enforcing the common rules. This practice is allowing us to continue the good quality over time.

I have always been shy of reading extra large text in the web. So, I thought I could better post this in two parts! I assure, next post will contain more images than texts, So, you better stay tuned for the next one...

Delving into client side capabilities of ASP.Net Ajax

I believe the client side scripting capabilities of ASP.Net Ajax is not utilized by many ASP.Net developers. This is most probably due to the fact that, not many people are aware of it at the first place. Also, since most of the javascripts are rendered secretly (read, not blatantly, which is good), most developers don't even feel the existence of the underlying javascript at all.

Two very simple examples of the client side library are given here as examples -

1. Did you know, if you have the following javascript method, it will be automatically called when your page's DOM is finished loading?

function pageLoad(sender, args) {
}

2. Do you know the following javascript code will add an event handler to catch whenever an asynchronous post back is completed?

Sys.WebForms.PageRequestManager.instance.add_endRequest(endRequestHandler)

These are just very little glimpses of the big scenario. To uncover more, visit the official MSDN documentation at http://msdn.microsoft.com/en-au/library/bb398822.aspx


If you are new to this, I assure, you will have a much better knowledge about ASP.Net Ajax scripting than ever before and can produce better quality javascript for your ASP.Net websites.


Happy digging!

IMPACTing for agile software development

Well, next time on a dev job interview when someone asks you the question, "Can you give us a brief idea on agile software development engineering practices?", you are probably gonna laugh on your mind and just answer, "IMPACT!". Yes, this is it, compact and right on target!

Today, I came up with this acronym about agile engineering practices and I think its a nice one :-)

IMPACT can be elaborated as follows-

I	for	Iterative and Incremental Development
M	for	Merciless Continuous Refactoring
P	for	Peer Code Reviews
A	for	Automated Acceptance Tests
C	for	Continuous Integration
T	for	Test Driven Development

For all you agile folks out there, I hope this IMPACT makes sense to you! I have found many people to take agile as a panacea and start getting skeptical as soon as they feel the heat in real life. Well, we all know, there is no free lunch! So, lets get our feet on track and do the first things first.

What are the first things? The answer is, IMPACT, if you really want to create a positive impact out of agile methods.

Comments are welcome!

RowTest Extension for NUnit

Well, I was just about to implement it myself! However, its good to see that the NUnit addin named RowTest actually allows us to do the data driven unit test through declarative programming and adding parameters to the dumb test methods!

http://www.andreas-schlapsi.com/projects/rowtest-extension-for-nunit/

Check out this website for an example and get started with RowTest.

Iterative and Incremental implementation of Code Reviews

Extreme Programming (XP) advocates for a pair-programming, taking the code review to its extreme. I have also found that pair programming generates a lot of speed and also helps producing better quality product in the first time. But, at the same time it's difficult to impress the management or prove return on investment associated with pair programming to the business people. So, what is the best possible solution? I believe, we can implement frequent peer code reviews to mimic the pair programming to some extent and get the benefit out of it.

In our team, we started implementing code reviews as we now recognize that there is no way to live without it. As usual, our approach is an iterative and incremental approach. So, we are taking small steps and eventually embracing the best practices in the team. I would like to share our plan here in this blog. The review process goes on the following work flow-

"When I am done with my work on task, I commit the code with the reviewer's name on the svn comment. CCNet automatically builds and sends a mail to the reviewer. The reviewer gets the review email through a filter and reviews the code and sends his feedback to me via IM/email."

Sprint #1: Review all the names or classes, files, methods, variables and so on. So, the reviewer emphasizes on the names and provides feedback on the following things-

1. Is the naming standard correctly followed?

2. Is this a meaningful identifier?

3. Does the name conform to the conventions used elsewhere in the code?

Sprint#2: Review the use of private methods and code structure. The to-do list is -

1. Would it make more sense to put some code into the private method for readability and/or reusability?

2. Is there any hard-coded constant directly used without referring to a const/readonly data type?

3. For all the methods, is it possible to reduce the dependency by using a simple parameter instead of a whole object?

4. Learn from sprint#1 and use the common learning.

Sprint#3: Review the use of loops, if-else blocks. At this iteration, the to-do is-

1. Is it possible to eliminate a loop?

2. Is it possible to avoid the nested loops?

3. Is there a large if-else-if-else block? Why is it required? Is this large conditional block a possible candidate for future change?

4. Learn from sprint#2 and use the common learning.

Well, this is pretty much it. The idea is, we feel its not practical to go with an overnight policy for implementing peer code reviews. But, its very much possible that we do it in small increments and at each sprint's retrospective we bring this point. So, we are all informed that we need to do reviews, which, eventually should sustain as a best practice!

If you think you have some ideas regarding this, please share it with me/my readers.