Nexus: Don't dive in until you know how to swim

When you adopt a new development tool how much time do you set aside to understand it? Do you just download a new tool like Maven, rip open the archive, install it, and just start clicking around? Or, do you read articles and books first? As we prepare to release Nexus 2.0, I’m curious about how current Nexus users adopted the tool. Leave a comment and let us know how you adopted and learned the tool, and if you had either positive or negative experiences.

My Assumption: Most of us don’t read documentation...

Based on my experience, I’m going to guess that most of us likely just dive into implementation when it comes to new tools and libraries. Even though one of my focuses is documentation, I’m only assuming that 20% of you read anything in the book prior to install. Sonatype understands this and with every Nexus release our engineers and product managers are trying to implement new features to be as straightforward as possible.

This isn't to say that we're no longer writing documentation. Documentation is essential when you are setting up critical, enterprise-grade development infrastructure. In my time consulting and training I’ve seen some really “interesting” builds that have developed from what I’m calling the “Just Dive In” approach: what happens when an organization adopts a tool before it understands what the tool provides or even what it is. What happens when you never take time to learn about a tool.

The “Just Dive In” Approach

This is a common malady for programmers, and we’re almost all guilty of this approach at some point in our career. Someone tells you to check out Hudson or Maven, you read some of introductory articles on DZone, and you immediately dive in. Even though you might only have a rudimentary grasp of the tool, you’ve converted your build over to Maven and Nexus. It’s full of duct tape because you didn’t fully grasp the Maven lifecycle, or you don’t use snapshots because you didn’t have time to learn about the differences between release and snapshot artifacts.

Note: I’ve been there. This is how busy developers adopt new technologies. You adopt a new technology like Spring or a new web framework by doing. Having time to read a full length book on a new technology is rare. My own theory is that it always takes two attempts to adopt a new technology with the first attempt being a dress rehearsal full of mistakes and missteps. So back to our example...

Maybe you make a mental note to purchase the book or take a training course on the technology... later, when the project calms down, but time moves quickly these days. Deadlines and meetings multiply and suddenly you find yourself unable to take some time out to really learn Maven or Nexus. All of a sudden your half-baked prototype become a production dependency.

Hoping you can swim...

As a consultant this is usually when someone calls me up and needs some emergency help. They migrated to Maven (or they set up Nexus) but they didn’t take a day to start from the fundamentals. A product deadline is approaching and someone needs to do the equivalent of open heart surgery on a non-standard build in the matter of days. Often the changes that need to be made to fix a build full of bad assumptions and introduce more compromises and workarounds. This is expensive, last-minute work that could have been avoided with training.

While most of us don’t read documentation, I think it is up to managers to make sure that someone in the organization has a grasp of the fundamentals from the very beginning. That’s my cue to tell you about our Nexus training class, it’s a comprehensive introduction to Nexus best practices and it walks you through the decisions you’ll need to make *before* you introduce a repository manager into your architecture. (Let's see that's a couple hundreds dollars vs. the price of an emergency consulting engagement - if you have a complex environment, I'd recommend the training first.)

Conclusion: Check out that pool before you dive in...

This rapid adoption trend has become more apparent in the last decade. As an industry we’re trying to create developer-facing APIs, tools, and frameworks that are simpler to adopt and use. While you should be able to get up and running with an evaluation of Nexus or Maven in a few minutes, we can’t let this simplicity keep us from a fundamental truth. When you don’t set aside enough time to learn a new build tool or piece of development infrastructure you end up with these half-migrated disasters that end up having to be rewritten often at the last minute.

If you want to avoid this situation, set aside some time to understand products before you dive into a production implementation. Understand the fundamentals of repository management and dependencies before you implement an enterprise-class build and Nexus deployment. Resist this urge to just get started and read the introductions to some of these books we've invested in before you start implementing a deployment. It'll save you time and money, I promise.