Wednesday, August 22, 2007
Developmental Integrity
byIt is not often you have the chance to coin a phrase, especially by accident. Yet occasionally a person is faced with a situation in which they are talking about something that has no good descriptive name, and are forced to make up their own. This was the case when I was trying to explain to my peers the relationship that existed between Software Reliability and Software Maintainability. And thus Developmental Integrity was born…
When I decided to focus my efforts in the area of Software Reliability and Maintainability, several of my colleagues asked why I chose to combine the two domains. Surely Software Reliability and Software Maintainability were large enough areas in their own respects, why make a composite of the two? My answer was that there exists such a complex and dependent relationship between the two that looking at one but not the other would be doing a disservice to the integrity of software applications as a whole. The two together described a sort of Developmental Integrity for an application.
The underlying idea behind Developmental Integrity is that both Software Reliability and Software Maintainability are affected by discreet changes made over time. Maintainability, as defined by IEEE, is “...The ease with which a software system or component can be modified...”. Ironically, the more maintenance changes made to a software application, the less maintainable the application is. This is because subsequent changes increase the complexity of the application, which in turn can lower ease of understanding and maintainability.
Reliability refers to the probability of the application to run without error. Software, unlike hardware, has no moving parts that can wear out. As issues with the software are reported and fixed through discreet changes, software actually gets more and more reliable over time. Therein lies the crux of this complex relationship. While reliability increases as maintenance changes are made over time, the effort needed to continue to further maintain that level of reliability also increases. This tendency for software to become difficult and costly to maintain over time is known as software entropy.
As long as this maintenance effort remains less than the effort it would take to refactor the application, the application is sound developmentally. Eventually, when the software entropy reaches the point that the effort to maintain the application becomes greater than the effort to refactor it, the application’s Developmental Integrity has been compromised.
After explaining this to my peers, I went on with my work, not giving a second thought to the way I had named the relationship. Imagine my surprise, when several weeks later I receive an email from another colleague who was not involved in this initial conversation. In it she referenced the idea of Developmental Integrity… Later, I also saw the term used again in an online software engineering forum. That’s it - I have officially left my mark on the Software Engineering world. Had I realized the term would be reused, I would have thought of a cooler term, like Alimentation Ability or Credibility Competence. Maybe I’ll keep a list of creative buzz words in my pocket, just in case it ever happens again.
