My Stuff

2010 Conferences

OSGi DevCon @ JAX London

February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox

EclipseCon

March 22 - 25 - Tutorial on Modular Architecture

Über Conf

June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture

Catalyst

July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.

Tweets @ Twitter

re: #apple event "We sold more iPads than any PC manufacturer sold of their entire PC line." 2012-09-12

re: #Apple Event ""Our notebooks now rank #1 in the US in Market share in the last three months." 2012-09-12

Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29

The #osgi alliance response (http://t.co/KrN8XNWg) to the @mreinhold #jigsaw announcement (http://t.co/9YvcDdqC). 2012-08-29

Good Q&A with @mreinhold on project #jigsaw. http://t.co/9YvcDdqC. Modularity will change the way we design and run apps! 2012-08-28

LinkedIn Profile

The opinions expressed on this site are my own, and not necessarily those of my employer.

Rotting Design

Filed Under Architecture & Design, Java, OSGi, Platforms |  

Design Rot

We’ve all experienced that sinking feeling when maintaining a piece of crappy software. Has my change broken the system in some unintended way? What is the ramification of my change on other parts of the system? If you’re lucky, and the system has a robust suite of unit tests, they can offer some support in proving your work. In practice, however, few systems have thorough automated test coverage. Mostly we’re alone, left to verify our changes as best as possible. We might privately criticize the original developers for creating such garbage. It certainly lends a plausble excuse in explaining why the maintenance effort is so costly or time-consuming. Or it might serve as the basis upon which we recommend a re-write. But mostly, we should wonder how it happened.

For sure, most software doesn’t start out this way. Most software starts out clean, with a clear design strategy. But as the system grows over time, strange things begin to happen. Business rules change. Deadline pressures mount. Test coverage slips. Refactoring is a forgotten luxury. And the inherent flaws present in every initial design begin to surface. Reality has proven that few enterprise development teams have the time or resources to fix a broken design. More often, we are left to work within the constraints of the original design. As change continues, our compromises exacerbate the problem. The consequence of rotting design is seen throughout the enterprise on a daily basis. Most apparent is the affect on software maintenance. But rotting design leads to buggy software and performance degradation, as well. Over time, at least a portion of every enterprise software system experiences the problem of rotting design. A quote from Brook’s sums it well:

All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing the original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress.

The most obvious question is, “How do we prevent rotting design?” Unfortunately, rotting design is not preventable, only reducable. As design is an essential complexity, it cannot be eliminated, only minimized. Of the past ten years, the design patterns movement has provided insight to the qualities of good design, helping minimize the essential complexity. Dissecting design patterns reveals many important design principles that contribute to more resilient software design. Favor Object composition over class inheritance, and program to an interface, not an implementation, are two examples. Of the 23 patterns in the GOF book, all adhere to these fundamental statements. Alone however, today’s design patterns are not enough to help reduce rotting design.

Reducing Rot

Most patterns emphasize class design, and present techniques that can be used in specific contexts to minimize dependencies between classes. Teasing apart the underlying goal of most respected patterns shows us that each aim to manage the dependencies between classes through abstract coupling. Conceptually, classes with the fewest dependencies are highly reusable, extensible, and testable. The greatest influence in reducing design rot is minimizing unnecessary dependencies. Yet enterprise development involves creating many more entities beyond only classes. Teams must define the package structure in which those classes live, and the component structure in which they are deployed. Increasing the survivability of your design involves managing dependencies between all software entities - classes, packages, and components.

But if minimal dependencies were the only traits of great design, developers would lean towards creating very heavy, self-contained software entities with a rich API. While these entities might have minimal dependencies on external resources, extreme attempts to minimize dependencies results in excessive redundancy across entities with each providing its own built-in implementation of common behavior. Ironically, avoiding redundant implementations, thereby maximizing reuse, requires that we delegate to external entities, increasing dependencies. Attempts to maximize reuse results in excessive dependencies and attempts to minimize dependencies results in excessive redundancy. Neither is ideal, and a gentle balance must be sought when defining the behavior, or granularity, of all software entities - classes, packages, and components.

Software design is a constant quandary. Any single element key to crafting great designs, if taken to its individual extreme, results in directly the opposite - a brittle design. The essential complexity surrounding design is different for every software development effort, for similar domains across organizations, and for different phases throughout the life of a software product. The ideal design for a software system is always the product of it’s current set of behavioral specifications. As behavior changes, so too must the granularity of the software entities and the dependencies between them. The most successful designs are not characterized by their initial brilliance, but instead through their ability to withstand the test of time. As the complexity of software design is an essential complexity surrounding software development, our hopes lie with technologies and principles that help increase the ability of your design to survive over time.

Future of Design

I’m hopeful that all software developers have experienced the pleasure of a design that, through the course of time, has withstood the test of time. Unfortunately, many enterprise development teams have too few of these experiences. Likewise, few enterprise development teams devote adequate effort to package and component design, serving as a significant contributor to our inability to realize the promised benefits of object-oriented development. It’s unreasonable to believe that even the most flexible class structure can survive should the higher level software entities containing those classes not exhibit similarily flexible qualities. The problems are rampant. Increased dependencies between packages and components inhibit reusability, hinder maintenance, prevent extensibility, restrict testability, and limit a developer’s ability to understand the ramification of change.

SOA and Web Services promise to remedy our failures with object-oriented development. While Services may offer tangible business value, within each awaits a rotting design. There exists a world between class design and web services that deserves more exploration, and as an industry, we are beginning to notice. Currently, the Java Community Process (JCP) is developing three separate JSRs that emphasize greater modularity for the Java platform. JSR-277 is creating a static module system for Java, part of which aims to establish a mechanism for expressing and enforcing the dependency between .jar files. JSR-291 references OSGi, a proven component technology providing a dynamic module system for the Java platform. JSR-294 focuses on VM and language support for modularity. For some time, Maven has supported flexible ways to select specific versions of a component, as well as support for managing transitive dependencies. JDepend and JarAnalyzer are two utilities that provide feedback on package and component design, respectively. All aim to help manage the complexity, from design through deployment, of enterprise software development. With each, new practices, heuristics, and patterns will emerge that increase the ability of a design to grow and adapt.

Comments

7 Responses to “Rotting Design”

  1. OSGi Post Summary : Software & Technology @kirkk.com on February 19th, 2009 8:39 pm

    [...] Rotting Design - Discusses how a system’s design tends to rot as change occurs, and what we can do about it. Introduces OSGi at the end of the post. [...]

  2. nWizard - Norbert Rakosi’s blog on Free Software development … JAVA … Personal Development… and … bad speling… » OSGi…on and on… on February 20th, 2009 2:31 pm

    [...] Rotting Design - Discusses how a system’s design tends to rot as change occurs, and what we can do about it. Introduces OSGi at the end of the post. [...]

  3. Richard Nicholson on April 4th, 2009 11:34 am

    Kirk,

    An excellent article! (Only just came across this).

    Succinctly summarizes the issues organizations face and the potential power of OSGi - as part of the solution. However - I fear that the majority of the software industry, architects and developers still fail to appreciate these fundamental issues.

    Regards

    Richard

  4. Software Rot - Manage those Dependencies : Software & Technology @kirkk.com on April 6th, 2009 3:46 pm

    [...] Rotting Design, I spoke of how software tends to rot over time. When you establish your initial vision for the [...]

  5. That Rotting Design : Software & Technology @kirkk.com on December 21st, 2009 4:29 pm

    [...] Note: This is a re-post, with slight modifications, from an entry in October 2007. And now, two years later, we’re just about there! For the abridged version of this post, focus on the text in bold. You can see the original version here. [...]

  6. Ramiro on December 5th, 2012 12:27 pm

    What i do not understood is if truth be told how you are no longer really a lot more smartly-favored than you might be right now.
    You are very intelligent. You already know thus significantly with regards to this topic, made me individually believe it from numerous numerous angles.
    Its like women and men aren’t involved until it is something to accomplish with Lady gaga! Your individual stuffs outstanding. Always maintain it up!

  7. nike store telephone on March 22nd, 2014 1:45 am

    nike store telephone…

    arts and crafts.5 : Nul criminal, Nul d?lit ne peut ?tre excus? ni los angeles peine att?nu?e que dans les cas et signifiant circonstances o? loi d?cre le fait excusable ou permet lui applir une peine moins rigoureuse….

Leave a Reply