I got into a series of interesting conversations with the usual suspects, Austin edition, about tools. I wouldn't say we covered what I'm about to outline here in totality; these snippets are only starting to coalesce and firm up in my mind.
What's a Tool?
It seems to me that a tool can start out as a thought construct, an observation leading to a human activity or operation. A practice, such as BDD, is a tool driven from a value system (quality, efficiency, etc.) that may manifest itself in a "hard" tool such as RSpec or NBehave. The hard tools are often used to streamline and satisfy an entire practice.
Lean Manufacturing calls these tools "monuments." That might not be a totally fair comparison, but I hope we can agree that you can install a practice tool (such as BDD) with a series of smaller hard tools such as MBUnit/NUnit/xUnit.NET, NCover, and a nice base class.
Lean has a very negative view on these monster tools, or monuments, because they create waste. The concept "right-sizing" is used by lean people to indicate that a tool should be exactly the size needed to allow a part or product to flow through a cell that adds value. How can you right-size a monster? You can't.
This leads me to question whether or not the tools we're using or developing aren't just the right size. I'm certainly looking at what we're doing at Xclaim with a critical eye. I'll say that we use small tools (e.g. we're not using NBehave) that are assembled/automated with a larger substrate (NAnt). The more I learn about the benefits of lean, the more I'm not into the bells-and-whistles approach to software tooling.
One Tool to Rule Them All
Why are we pursuing this IDE business? Ok, ok, so they make good "product." And, yeah, sure, I understand the powers of static analysis now we can have an HUD hovering over our code giving us some quasi-futuristic view on the code we're writing.
Snowcrash IDE anyone? This is a vision that appeals to the science fiction reader in me, but I think we might be off on a bit of a fool's errand here. Let's get pragmatic, shall we?
We have a perfect substrate for integrating a series of small tools: the command line. No doubt when working with C# or Java it's nice to have refactoring and analysis support in our editor, but it's an editor folks. Too much focus is put on making this our only touch point, our only tool in craft. It's as if some day in the not-too-distant future we'll boot right into Visual Studio. When that's the case there goes my flexibility. In this future on the .NET stack I have a single trickle into my value stream: Microsoft. Should I want to extend the value of that environment, I'll have to go VSIP or accept their tributary as input to my value stream. Limiting factors abound and I'm not bullish on the future of "value stream operator" as a tenable business model.
Tool Evolution
We should, as an industry, evolve focused tools (think: a surgeon's scalpel) from larger conceptual tools. NAnt or Rake are perfect examples. These are specific tools that "pull" (another lean idea) a larger tool of continuous integration into possibility. We'd of course need a version control tool to satisfy CI and we've got a number of those. Notice how there's not one thing doing it. Take note that Victronix doesn't have the "Swiss Army Knife: Surgical Edition" in their product line.
What's the advantage of this approach? Chiefly: we can tweak our production lines to product design. We can tailor our process to match the pain we feel and the quality/productivity demands we're after.
A tool should start large as a practice. A practice should satisfy a number of values. From there we should build/buy/introduce the necessary automation (and only the necessary automation) to satisfy a particular project. These small component tools should be flexible and easy to patch into a bespoke and context-driven orchestra aimed at eliminating wastes common to every or, key point coming up, unique to each project.
What's thrilling and cool about the right-sizing approach to tools is now you're better able to improve at the systemic level. I'm going to make damn sure, while keeping an open eye, I don't get suckered into software gadget culture.