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)
|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.
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.
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…