Flight Plans, Stormy Requirements, and Other Extremes


from five different legacy systems describing nursing visits to patients. Core elements included collecting the data from the systems, modeling it, normalizing it, and then generating reports off that data. The business group could only imagine the tip of the iceberg of the kinds of reports they could get. Ideas about how to validate this operational data against hard accounting data were just emerging. So we departed with a broad plan that tackled the fundamentals: data acquisition and normalization. We then built some rudimentary reports. This approach helped us get high enough that we could see over the horizon. And I suppose like during a scary flight, we saw a lot of storms.

Measurement is critical to Extreme Programming. You must measure your progress closely because it is the only way to be sure you are on track. With each measurement, you correct. Start with small, achievable components that can be verified with unit tests as soon as you create them. If your project is like a flight of 400 miles, consider points that are 25 miles apart and make those small segments a trip in and of themselves. Once you are 25 miles down the road, make sure all is safe with the sponsors, testers, and other project participants, then do the next 25 miles.

In the datamart project I described, the first part we focused on was data collection and normalization. Once that was pretty stable, we proceeded with our first reports on the Web. Next, we came up with validation methods that tied back to the accounting system-which helped us refine our normalizations. With better data validity, we were able to add more detailed drilldowns and different dimensions to the reports that could only be fully conceptualized once the data elements were refined.

Have courage. You might go along the way and see an insurmountable wall of thunderstorms ahead of you. In fact, they may be closing in around you. Don't get cornered. Turn around. Get yourself out the way you came in. Regroup. Get some information from external resources that help paint a more complete picture. With the new information considered, get right back on with it.

When we first started the datamart project, we totally overloaded our SQL 6.5 database. The entire load routine was defective, and it was not broken into small enough units. In effect, what we were developing was a consistent method to crash SQL, and we soon became experts at rebooting. So we regrouped. We rewrote part of the normalization as a simple, text-based, pre-cleaning program. We then broke the one database into five-to more logically model the five feeder systems that were in place-and achieved reliable and dramatically faster load times.

Software projects cover a lot of ground. The secret lies in small, achievable goals-each one providing safe refuge and alternatives if the unexpected occurs. The continual iterations gradually fit together to cover the distance from departure to destination. The ground gets traversed and a path is carved through the many obstacles. That 400-mile trip may take 475 miles of ground to cover, but that is what conditions dictated. The goal should not be to cover a 400-mile trip in 400 miles. The goal is to get to the destination in the minimum time that is consistent with the reality of the presented landscape.


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.