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:
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.”
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.
A component, Lattix LDC, to run in builds to generate reports about dependencies.
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?
Previous Topic
