The value in the Agile Manifesto I find myself citing most often in my work "Individuals and interactions over processes and tools." Too often people start with technology and tool questions and then end up with unhappy and under-performing teams as they try to make people work with "the right" tool rather than the tool that would be most productive. I  hear this a lot when it comes to version control and build tools; people start with the "what tool should I use question" before they even think about how they should work. An extreme example of this was a company I was at a few years ago which had an version management  tool that did not meet their needs at all. We didn't switch because management decided that what they really needed was a big expensive tool which was out of their budget range. So switching to a free tool like CVS did not even get on the radar. So I'm always careful to point out that you really need to think about what you do first, then pick a tool.

But what if the tool is designed for your task? can we learn something by adapting our work style (and even our software architectures) to the way that the tool works?  As I use maven for managing the build aspects of my projects I am finding some good example of how adapting your process to the right tool can be very beneficial because you are learning from a community of people who really thought through a problem. The risks is misunderstanding how close the tool's model is from your view of the world.

An example of this is how you start up an java application. Many applications ship with a script that defines the java class  path that defines all of the libraries that your application depends on. All of these dependencies are included in the maven Project Object Model file (or POM) which specifies what you need to build and test a project. Since I hate copy and paste work I wondered if there was an easy way to get the classpaths out of the POM and into a script. As it turns out, there isn't an standard way to do this. You can always build an extension to maven (one of the nice features of a good tool: extensibility), I really would prefer to use the tools that are available. What maven does let you do is to easily embed the classpath into the jar so that you can start up your application like this:

 java - jar myJar.jar

 rather than with a script that specifies the classpath. The side effect of this is that you no longer have an easy place to tell  the application where to load additional files from. Under the "script" approach you might add a new directory to the classpath. Now you need to be a bit more creative. (One way is to use classloaders.) 

By trying to adapt the architecture to fit what the tool supported we ended up with a simper, more explicit start up process. 

Even if you are not a Java developer, there are a couple of interesting points to walk away with:

• Some tools are built for a specific application, and the creators of  those tools have thought a lot about best practices.
• By trying to fit into the model that the tool supports you can use the tool to prevent making mistakes in your application design (even if it is a build tool and not a design tool)
• You need to be careful that the tool really is geared towards your application otherwise you  will fall into the trap of making your work fit the tool for the wrong reasons.
• While extensibility is a good quality of a tool, there is something to be said for laziness.

Comments (0)

Write comment

Show/hide comment form