With only one week before the annual Click Compliance Consortium meeting in Chicago, the office is buzzing. The agenda is firming up and it looks like we’ll be hovering near record attendance levels. Each CCC has it’s own flavor thanks to the fact that it’s really an event hosted, presented, and attended by members of the consortium itself – yes, that means you. Of course there’s always the expected presentation by those of us at Click Commerce, but it’s learning what all of you are doing and the free exchange of ideas that I look forward to the most.
This year we’re trying something different that I’m excited about. On the second day the agenda splits into three tracks and we all get to spend a couple of hours in an open discussion about one of three topics: IRB, Grants, or Animal Operations. I, with the help of a couple of customers, will be moderating the Animal Operations discussion and I hope those of you with interest will be able to join in on the conversation. I hoping that this will be a lively session.
Closer to home, I’ve been continuing the drive to refine our development practices. I’m not quite ready to share any results but here’s a short list of things we’re working on:
Formalization of best practices related to the development of reports using SQL Server Reporting Services.
We presented on this at C3DF and I’ll touch on it again during my CCC Reporting presentation. We’re currently experimenting with different applications of this technology so that we can determine the situations where it is a good fit and, equally important, where we would recommend other approaches.
Automated Testing
I’m especially excited about our early progress on this topic. One of the biggest challenges in any enterprise scale development project is knowing that the most recent change has no adverse effects. Did this cool new enhancement break any pre-existing capabilities? What is the performance impact of this new enhancement? We’re currently implementing automated tests for a large IRB project using three open source tools (Cucumber, Watir, and Celerity). It’s amazingly rewarding to push a button and see the browser run through an entire workflow scenario without any further assistance from me. I’ve come to really like the color green, which is what the final report shows for tests that pass. When I see red on the other hand, representing failed tests, I get a strong urge to immediately make it green. I’ll definitely be blogging more about this in the future.
Introduction of Agile development practices
One of my own personal goals is to improve the way information flows from Project Manager to developer, provide a more real time snapshot of the status of the project, and establish good development techniques early in the project before the stress level is too high to want to try something new. For all of these reasons, I’m a fan of an Agile development methodology. In my mind, the development model I prefer is to establish a routine from the beginning of the project which is based upon a repeating cycle of development that involves these elements:
- Establish 3 stores: Development, Test, and Future Production. The development store is integrated with Source Control from day 1 and implementation is broken down onto 2 week iterations. At the end of each iteration a patch is created and applied to both Test and Future Production.
Test is where all user acceptance testing takes place. Testing on the development store is limited to the developer’s themselves testing each other’s work as part of unit testing.
Future Production starts out as a pristine store, empty of all data and is given the white glove treatment. As patches are built after each iteration, they are applied to this store to keep it up to date. In this way, we have a clean store to use when going live without first having to worry about clearing gout all the data that collects through the course of development and testing. - Only update Test and Future Production via patches. This means that the same process we recommend once your site is live is enforced early in the project. In my mind this has many benefits. It means that by the time you go live, this process is second nature and it avoids the “deer in the headlights” feeling of being asked to introduce this process at the time of going live, which is a time when you are already stressed about a lot of other things.
- Test incrementally. Thinking about how to test the entire system all at once is a bit frightening. Though the process of applying patches after each development iteration we can parcel out the testing burden and at the same time get end user feedback much earlier in the development process when there is actually time to properly respond.
As a part of this effort, we’ve also been piloting the use of a new tool to help us track all the development and so far it’s being received well. At the end of our pilot, I’ll post a summary of our experiences and conclusions.
I look forward to seeing all of you at the CCC conference next week in Chicago!
Cheers!
