Summary
I'm curious, how many developers spend time consciously designing and managing relationships between physical entities?

One of the most challenging aspects of software development is managing and enforcing design and architecture. An elegant conceptual design can quickly evolve into a tangled mess during implementation, where not one developer grasps how the high level vision has manifested itself in code. Attempting to understand and manage design and architecture by manually synchronizing documentation with a constantly evolving code base is a lost cause.

The problem grows worse for large systems developed by large teams. Attempting to manage the logical dependency relationships between thousands of classes is fruitless. While TDD can help, this is even difficult because of the wide array of experience found among the development team. Basically, some developers are better at TDD than others, and it's difficult to police everyone on a large team. It might be possible to manage relationships between packages, but even this can be difficult for large systems where you might have hundreds of packages. And logical dependencies really only address the maintenance issue of software, but do not help much to promote and facilitate reuse.

While we certainly cannot ignore the logical dependencies, for large systems we also need to manage the phsyical dependencies between the deployable units. In Java, these units are .jar files. Even for large systems, there usually exists a manageable number of .jar files. Understanding the physical dependencies between .jar files helps with maintenance since we'll know the ripple effect of change, and these physical units are also the foundation of reuse.

But anything done manually is open to error, and requires a high degree of discipline to continually manage. Since I program mostly in Java, I've been very keen on managing and enforcing these physical dependencies. Recently, I've been working on two projects to help manage physical dependencies. The first is JarAnalyzer, a utility that can analyze a directory of .jar files, and report on the physical dependencies between each. It's certainly in it's infancy, and I have plans to continue it's development, but I also think it's stable enough to share. The second is a pattern language to help manage physical dependencies, which can be found at Extensible Java. I'm interested in your feedback on either, and am also very interested in hearing how (and if) you manage your physical dependencies.

Talk Back!

Have an opinion? Readers have already posted 19 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Kirk Knoernschild adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Kirk Knoernschild is a hands-on software consultant with over ten years of industry experience, and is passionate about using leading best practices to build better software. Kirk is the author Java Design: Objects, UML, and Process, published in 2002 by Addison-Wesley. He frequently contributes to various technical publications, and actively updates his personal website, www.kirkk.com, with new articles and whitepapers on a variety of software development topics. He is also the founder of www.extensiblejava.com, a growing resource of design pattern heuristics in Java.