DevOps Zone is brought to you in partnership with:

Leaving university, I thought I'd be a developer happily knocking out code but was always drawn to tech support. How do we help people use our tools better? Now, I mostly specialize in consulting and introducing new customers to our tools. I am a Tech Evangelist and Lead Consultant at Urbancode. Eric is a DZone MVB and is not an employee of DZone and has posted 82 posts at DZone. You can read more from them at their website. View Full User Profile

The Curse of Tool Blindness: Maslow’s Hammer

08.23.2012
| 8385 views |
  • submit to reddit
A hammer and a screw

That ALMOST looks like nail. Doesn't it? Image courtesy of Justin Baeder

In 1966 Abraham Maslow said, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” Maslow gave us all too much credit. When we have a hammer and know how great it is, we not only treat everything as a nail, we actually perceive everything to be a nail. One develops a blindness to “non-nail” problems and creative problem solving takes a back seat to picking up that hammer and smashing the problem.

For those of us in the tool-making business, this blindness can be our greatest weakness. We know our tools extremely well, and know how to bend them to purposes outside their sweet-spot. When users talk about those related uses, we have the opportunity to recognize a new market for a new tool. More often than not, we apply the existing tool blind to the opportunity.

When all you have is a continuous integration system, everything looks like a build.

In early 2002, we at Urbancode released our first commercial version of AnthillPro. At the time it was team level build management and CI tool – something like the open source CI tools you find today. Within three months of release, questions asking, “So, now that I’ve solved build, how do I deploy this thing to QA and Production?” starting hitting the mailing list. Those questions never stopped. It took us several years to realize that we needed a special kind of build to handle deployments and several more to realize that deployments are not builds and needed a very different model. It was 2006 before we introduced AnthillPro 3, which had a genuine distinction.

At UrbanCode we weren’t alone in making this mistake. In fact, it is the most normal thing to do with a CI system. I’ve seen dozens of Hudson/Jenkins instances with a list of projects looking like:

  • My Project
  • My Project Deploy Dev
  • My Project Deploy Production
  • My Project Deploy QA1
  • My Project Deploy QA2
  • My Project Deploy SIT
  • My Project Deploy Stage
  • …. and on and on

Over and over again, I hear that this setup in Jenkins is hard to maintain and a mess to view. It sure is. Abuse of tools is never pretty.

Today, UrbanCode offers both AnthillPro which provides both build and deploy tools in one package (Swiss Army Knife style) and uDeploy which focuses strictly on that deployment problem.

The creation of uDeploy prompted us to go back and look at the deployment problem with fresh eyes. It turned out that what had seemed like a rare challenge in AnthillPro suddenly was the most normal problem in the world. Everyone needed to coordinate the release of multiple builds. In AnthillPro we had picked up the hammer of “Build Time Dependencies” and smashed that problem down by creating a “Build of Builds” and deploying that. If you read Chapter 13 of the Humble/Farley Continuous Delivery book you’ll see the concept of an Integration Pipeline which also calls for this goofy build of builds. All the guys with hammers see the same nail.

Tools and Language

Part of the problem is that tools impart vocabulary. In Continuous Integration, we were over-focused on doing a build that tested itself. That slowed the transition to secondary processes that were outside the build and tested the build.  In a Continuous Delivery system, we think in terms of builds and promoting those builds. As Jez Humble points out in response to Stephen Smith’s critique of the build of builds, the valuable part is the manifest of dependencies. Once we stop thinking of the manifest as a strange build, and instead as it’s own thing, solution spaces open up. In uDeploy, we call that manifest a Snapshot. Language is critical to how people tackle problems and value options.

Looking around the industry, others fall victim to the same patterns of thought. Companies that are really good at provisioning virtual machines will see application deployment as an extension. Source control vendors don’t distinguish between ideal storage for source and built binaries. It’s nearly ubiquitous.

So What?

Normal people who use rather than make tools need to be doubly aware of tool blindness. As tool users, we need to be cognizant of when we are using a hammer on a screw but we also must beware of our tool providers telling us to do so. When working with vendors, you do them a massive service when you say, “You know this is lame, right? This feels wrong.”

For product companies, taking off the blinders is extremely difficult. As an industry we all get better when we manage it. Keep working at it.

Published at DZone with permission of Eric Minick, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)