XmlObject - Adaptive Object Model

Better Designs Faster

Adaptive You Say?

Ok, so you might be thinking, Adaptive Object Models allow one to solve some crazy complex problems.  My problems tend to be more normal and perhaps Adaptive Object Models aren’t required to solve normal problems?

In keeping with the agile philosophy of simpler being better, I would be the last one to advocate using a complex solution when a simple one would do.  For example, an adaptive object model would clearly be the wrong choice for a prototype.  A prototype should explore a concept with as little overhead as possible.  This is also true for problems that are well defined, well understood, and are not expected to change over time.  If you are building a solution for a problem of this type then it is likely that you can implement a quicker and less complex solution using a static or dynamic object model. 

So, for problems where there is very little understanding and for problems where the understanding is complete, my advice is to not use Adaptive Object Models.  That leaves the part that is in between.  I don’t know about you but I have spent most my time smack in the middle of this spectrum. 

In the course of my research I came upon a paper authored by two of the heavyweight thinkers in the Adaptive Object Model space, Brian Foote and Joseph Yoder [Foote & Yoder 1997].  The paper is titled Big Ball of Mud.  It dramatically influenced my understanding of architectural patterns and software development as a whole.  The paper describes a pattern that I have encountered many times over in my development career.  If you’ve not read this paper I strongly suggest that you stop right now and go read it.  What Mr. Foote and Mr. Yoder have to say will help you more than anything I am likely to say.  Then, once you are done and if like me you seek solutions to your own Big Ball of Mud, then return here.  Perhaps Adaptive Object Models can guide you to dry land, much as they have done for me. 

I am going to use two examples to illustrate how Adaptive Object Models have helped my development efforts; requirements and testing

In my current software projects we probably put more effort into requirements than any other aspect of our development.  We have individuals whose sole assigned job is requirements and requirements management.  We hire good people with the right skills.  We get them training and proper access to the customer.  We have a wealth of existing development and applications in the field that we can mine for data.  We use this data as a baseline for developing new requirements.  We do clinical trails and we beta test our products.  By all measures we should have the best and most timely requirements possible, and yet we still struggle.   After many years  I have concluded that the requirements problem, as a whole, is intractable and that it will never go away.  That is, no matter how much time and money we throw at it, we will still have trouble defining requirements.  I am not suggesting that we can quit.  Not at all, I am simply stating that the problem requires new thinking along some new fronts. 

Some years ago Kent Beck and his agile cohorts recognized the necessity for allowing requirements to change.  Their solution was to invent a process where requirements are allowed to change as they are discovered.  While I think there are problems with this philosophy, I nonetheless, believe it is a step in the right direction.  Once we accept that requirements need to change then the problem simply becomes one of how to best accommodate this change.

I like to think of ever changing requirements as a variation of Heisenberg’s uncertainty principle.  That is, the very act of implementing a feature will change the understanding of the feature, often resulting in a change to requirements.  Unmanaged, such changes will are a moving target and will forever keep an architecture obsolete.  This problem is exacerbated when software is released.  When that happens not only must the architecture provide for the change, it must do so without breaking functionality in the field. 

Which leads me to my second illustration, testing.  Again, some of the most dedicated and hardworking people I know are software testers.  My current employer routinely asks them to do the impossible and fortunately for the most part they succeed.  However, they succeed with considerable risk.  What if we were working on systems that were less tolerant of risk.  Today  the news is full of stories of testing failures in the medical industry.  Tomorrow it will be some other industry.   These failures cost millions upon millions of dollars.  How can we know that a given software artifact is safe?  It is simple, we can know it is safe by not changing it.  We build confidence in software by testing.  We destroy that confidence by making changes to tested software.  The longer we can go without changing a component the more confidence we will have.

This is where Adaptive Object Models step in.  With Adaptive Object Models it is a relatively simple thing to add new functionality without disturbing existing functionality.  If necessary, this can be extended to the point where existing artifacts are not recompiled.  With experience, and by exercising restraint, a seasoned developer can add functionality to an Adaptive Object Model, without changing a single existing line of code.  Testing will continue but it will focus on the new parts.  This saves time and money.  Moreover it inspires confidence, confidence that we can respond to changed requirements without sacrificing quality (or the testers).  Adaptive Object Models are the best solution I’ve yet discovered for dealing with changing requirements while limiting changes that would otherwise require testing.

Adaptive Object Models help in many ways beyond these examples.  However, I doubt that there are better examples or ones with more potential to help the bottom line.

XmlObject Guy