XmlObject - Adaptive Object Model

Better Designs Faster

Quality Data Models

Given an application or development effort, how might one go about measuring overall quality?  An interesting perspective on this is detailed in the paper A Copper Bullet for Software Quality Improvement by Michael Blaha [Blaha 2004].  The paper suggests that a good way to determine overall quality is to reverse engineer the underlying data store.  Every application, from the smallest embedded program to the largest distributed application has somewhere in it a data store.  Database theorists have developed a technique called normalization as an effective measure of the underlying quality of a database.   The theory suggests that an application with a data store in Third Normal Form is likely to be of higher quality than an application with a data store that is in First Normal Form.

I intuitively feel this is true.  In any code review an instant red flag for me is two pieces of data that look to be the same but are held in different structures.  Sometimes the similarity is intended and benign.  Other times it is unintended, unrecognized, and the source of much of the accidental complexity that Brooks mentions in his work No Silver Bullet [Brooks 1986].  When I first read Mr. Blaha’s article I instantly went to how one might use the idea to do better architecture.  I do most of my development on medium to large applications destined for the personal computer.  The thought of creating an entity relationship diagram never occurred to me.  Even if it had, prior to the XmlObject Framework, I am not sure how one would go about carrying out the analysis.  

On the home page I state that the XML metadata for a XmlObject Framework application could take any form.  While this is true, we don’t have to be stupid about it.  XML is the perfect medium for designing well structured data.   We can easily draw upon the decades of experience that the database folks have accumulated and use that knowledge to design better applications. 

Now when I start a new development, long before I create that first line of code I create an Entity Relationship Diagram.  Once I have the diagram I create sample data and immediately start the peer review process.  It is amazing the number of problems that one can work through with just a little data.  Once the data starts to come together, especially for large applications, you can create an XML schema.  With a schema in revision control and by using a validating parser, accidental complexity due to inappropriately cached data will be much less of a problem.