It seems that everyone has their own methodology now. It may be TDD, XP, Agile, RUP or some other flavour of the month. Last night, while I was less than sober, I had a conversation with Mike about two things that are usually last minute thoughts during the software development lifecycle: Reporting and Installation scripts.

I’ve built reporting solutions for years and in that time I’ve used a number of products including Crystal Reports, Active Reports and more recently SQL Report Services. During all that time I’ve also worked in companies where I’ve had to spec new software development and spec configurations for meta data driven applications. Through this time I’ve been unknowingly using a methodology that I’m going to call Report Driven Design.

During software specification we usually focus on screen design, business rules, architecture and, from these other considerations, we determine a database design. So what have we done through this process? We’ve figured out how to get data into a system and store that data. But what good is a piece of software that only consumes data? There are some out there that will do this, but in almost all cases business will want to gather the data, store it and then be able to extract the data in a meaningful way. I’m not sure why we regularly over look extracting the data in a way that provides business value.

One of the most powerful ways that I’ve found to truly understand the need, power and requirements of a system is to analyze the reports that the business users want to receive from it. This gives you great insight into the data that will need to be gathered, what the business domain terminology is, and how data may be optimally stored. More than once I’ve asked the business, in the very early stages of design, to provide me with mocked up reports that they would like to see the system produce. Analysis of report mockups allows me to see how the data relates to each other, which I can then use to create a logical data model, which provides me with business domain terminologies, which puts me much closer to the level of the business user.

The end result of the RDD is that I have an extremely solid understanding of data relationships, a common ground for discussions with the business users and a quick advancement into the SDLC. Now I’m not proclaiming that RDD is a magic solutions. So far it only works for me. I just wanted throw it out there so that people might begin to take reporting requirements into consideration during the design phase of their next projects.

I’m the Igloo Coder and I have to do some reporting as it seems like I was a little over quota this year.