Skip to content

Lattix Briefing: Dependency Management

Lattix - LDM 3.0  Screenshot

James and I talked with Lattix yesterday morning on the topic of their newly announced LDM 3.0. Lattix provides software that helps expose and manage dependencies in software, in particular large systems. To use one of my old phrases, dependency management is one of the dogs people kick on the way out the door (like unit testing). Who is that dog? The idea that different parts of your software should or should not require other parts to function. Spanning that checking into “non-code” components like databases could also be handy.

Why do you want to limit dependencies? In short, the more self-standing each part of your code is, the easier (faster and cheaper) your code base will be to change affording it a longer life. Object oriented programming, esp. strongly typed systems are rife with dependency concerns and patterns like using interfaces are one result (or driver) or this.

The concern is less important in smaller and more pristine code bases. But, once you start dealing with legacy code, esp. when you’re parachuted in to “clean up” a code base, having a tool that helps you expose and then enforce dependency rules could be useful.

What it Does

Lattix provides 3 ways to inspect for and report on unwanted dependencies in Java, C/C++, .Net code as well as Oracle databases and stored procedures:

  1. The core tool, Lattix LDM, inspects a code base, now including databases, and allows “architects” (or whoever has this responsibility) to establish dependency rules. For example, “classes in the package ‘com.acme.utils‘ cannot depend on the classes package ‘com.acme.bizlogic.'” As you’re inspecting the dependencies, you can create and assign (?) work items to “developers.” For example, “com.acme.util.Parser depends on com.acme.bizlogic.WorkOrder. Please refactor the code so that it does not.”
  2. An Eclipse plugin, Lattix LDM for Eclipse, that displays the work items from the tool and also displays dependency violations in realtime. The second allows “developers” to fix dependency violations before they’re committed. There’s also a similar NetBeans plugin.
  3. A component, Lattix LDC, to run in builds to generate reports about dependencies.

They get super-kudos for listing their price chart on their page.

A Culture of Cleanliness

The idea of keeping your code in a healthy state is always attractive. Unfortunately, many shops don’t internalize the ideas, favoring delivering software (near) on time instead of sacrificing features or time for quality. There’s always tomorrow to fix that stuff, the culture-think goes.

As an example, I’ve seen Agile teams that look poorly on spending time “cleaning up the code.” Of all mode of development, organizations that are doing Agile development should value code health as an implicit feature all customers require.

To be fair, part of the motivation to saying “no” to the request to “clean up code” is a mistrust of the developers intention. The developers may be gold-plating when the steaming pile of code will work “good enough.” As a counter “to be fair,” decision makers often lack the technical skills and code-base knowledge to do an accurate risk assessment of how long that steaming code can be left alone.

That’s one of my pet anti-patterns: software companies love to hire technical people and then ignore the strategic, yet highly technical, advice they give.

The larger point is this: if you’re really going to care about code base quality, make sure that you do more than just run reports, actually fix problems that you find. Making that part of your code culture is key.

Suggestions for Lattix

  • As with all commercial “tool” vendors, my primary marketing advice is to give free copies to prominent open source teams. Countless tools vendors have used this approach effectively, such as Cenqua with Clover. As with any brand marketing, the idea is to get exposure by giving the product to “celebrities” and other high visibility folks. Less mercenary, it’s the right thing to do with respect to the open source community: everyone owes them.
  • The work flow and code-context nature of Lattix seem like a good fit with Mylar. As an “architect” finds a dependency problem, they could pickle the context, open a work item in Mylar, and then send that context and work item on to the “developer(s)” who’ll fix it. In fairness, it might be worth the Mylar folks engaging with Lattix to have an example/RI, 3rd party integration use of Mylar. (That said, James may be right that larger enterprise systems would be a sweeter spot for Mylar.)
  • Over the next several years, dynamic languages such as ruby and JavaScript, all mixed with a healthy dose of HTML and CSS, will constitute the “steaming piles” that architects and developers will have to deal with. I’m not sure what Lattix would look like with when supporting the AJAX world, but I’d look towards Firebug as a starting point, inspiration, and perhaps collaborator.
  • The Lattix product is largely a “feature” at the moment. That is, it’s interesting looking technology, but not so much a stand alone product. Now, the company is small, so that might be just fine for the growth desires of the Lattix folks. To grow from being just a feature, however, I’d want to see Lattix take on the persona/misson of being about and providing tools for code health. Dependency detection is certainly important, but there are many other code health issues that could use tooling. As mentioned above, a culture of cleanliness is the second half of using tools like Lattix effectively on a code-base. Expanding out to becoming “the code health people” could put Lattix as a company and brand in a good position to be an expert and steward of that culture…leading to having more products, features, and services to sell.

Open Source?

As a final note, I could have sworn there are a handful of open source dependency inspectors. A (too?) quick search didn’t bring any up. At the very least, there’s a maven or ant plugin that generates these reports. Or, am I imagining those?

Disclaimer: Eclipse and Sun are clients.

Technorati Tags: , , , , , , , , , , ,

Categories: Enterprise Software, Programming.

Comment Feed

6 Responses

  1. I would be asking questions about reflection, and run time v. build time dependency – ie, is the analysis entirely static and can it distingish between build and production dependencies*?

    Can the tool analyse a code base for mismatched versions between developers? That is, where one developer is depending on v1.2.3 and another is using v1.3.2. This is/was a big deal in Java. Practically speaking if it can scan a BEA/JBoss/Websphere/JoNaS platform jars and reverse engineer the dependency constraints, that would be something.

    "I could have sworn there are a handful of open source dependency inspectors"

    In Java. I use JDepend a lot – it's primary value is that it uses Robert Martin's metrics for coupling/cohesiveness (more subtle and more useful than "thou shalt not").

    "but there are many other code health issues that could use tooling"

    Another tool is Findbugs – it analyses code for design smells, which is more general than dependency analysis – useful as the basis of a code review.

    * if you look at the Hibernate distribution, they split the jar base for you along these lines. Ivy (the dependency manager extension to Ant) can also be used to declare build/test/runtime dependencies.

  2. I have also had good results using JDepend. Another open source tool that I used was Dependency Finder. Two other open source tools that look similar but that I have not tried are Classycle and XRadar.

  3. come on Bill- you think we didn't ask about runtime/design time dependencies – what do you take us for? 😉

    the version mapping is a great question.

    Seriously – this is all about design time at the moment. As Cote says, currently Lattix is an implementation of an idea-using system dependency maps in this way-but its very early days in terms of function. I started asking about CMDB and all sorts.

    Thanks muchly for the OSS dependency pointers Bill and Gregg.

  4. oh yeah – I just wanted to comment on how your writing is coming along Cote. You were already good, but there is an economy and clarity of purpose coming into your writing that I can only envy.

  5. Bill & Gregg: yes, JDepend was exactly what I was thinking of (as in “couldn’t remember). I remember getting transfixed on the new vocabulary of Afferent and Efferent, staying on the lookout for excuses to use them. One of my old BMC buddies is a huge fan of FindBugs and I know it’s a good tool if the team is willing to react to it: that is, fix the bugs it finds. And thanks, Gregg, for the other pointers. Those are handy.

    James: thanks for the compliment!

  6. You might also be interested by the tool NDepend.

    NDepend analyses source code and .NET assemblies. It allows controlling the complexity, the internal dependencies and the quality of .NET code.

    NDepend provides a language (CQL Code Query Language) dedicated to query and constraint a codebase.

    It also comes from with advanced code visualization (Dependencies Matrix, Metric treemap, Box and Arrows graph…), more than 60 metrics, facilities to generate reports and to be integrated with mainstream build technologies and development tools.

    NDepend also allows to compare precisely different versions of your codebase.

    A java version is under development.