|
I value Individual and Interactions over Processes and Tools, but I am wondering what I can learn from my tools.
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.
I'm thinking that my experience with maven is not the only example of this. I'll have more to say about this later.
Comments () |
 |
|
|
|
|
Blogs 
