Early Tool Theory

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.

This entry was posted in lean, opinion, tools. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

9 Responses to Early Tool Theory

  1. Dave Laribee says:

    @David – Me too. I think you need a nice editor with the associated static language driven features: navigation, refactoring, analysis. But, out-of-box, VS is rather beefy. I’d prefer to see the editor stop there. Haven’t tried studio shell and there is rumor of “Emacs .NET” but I’m afraid that’s going to come with the D Language baggage (e.g. XAML everywhere). I’m not convinced of this vision either way… jury’s out for me.

  2. Hi Dave,

    How do you feel about reliance on VS.NET/Resharper for code editing?

    Personally I’d love to go back to a simpler/more focused editor, but can’t see how I could do without all the help ReSharper provides. :S

  3. @Dave,

    Change is happening, it is just slower then we would like.

    Example, just today a developer at my new client gave me this quote.
    ‘….after running a couple of tests on the BLL i cann see its value…i dont think i want to go back to the way i used to test things’

    This is in regards to showing him testing with NUnit. He had no prior experience with any testing framework. In fact, prior to my joining the team, they had ZERO tests. That to should be changing, but may be slow…

    If today I converted one person to see the ‘other side of the coin’ we have one less hurdle in our way.

  4. Dave Laribee says:


    > And until this changes, software companies (for profit ones) have more incentive to target products towards the masses (makes them more money) then to target them towards us.

    Bingo. That’s the problem. Managers/owners are optimizing the wrong thing. Give me a company focused on client pull and I’ll kill the competition any day. We might be ahead of the curve, but I believe we’re right and am willing to fight with that change. Realism should in no way obstruct us from the pursuit of excellence.

  5. @Dave,

    Again, I agree 100% with what you are saying in regards to the intent of the post. I was just pointing out the reality, as I have seen it. There are more ‘chop-shop’, ‘Rad Only’ developers out there then we want to admit to. The biggest problem with many of these small tools/practice tools is there is little-to-no documentation out there on how to use it. Be realistic. MOST people will abandon a product if they cannot get it working within 5-10 minutes.

    I know myself I am always trying to find a better way (kinda why I am an Alt follower/preacher), but let me tell you. There are much less of ‘us’ then there are of ‘them’. And until this changes, software companies (for profit ones) have more incentive to target products towards the masses (makes them more money) then to target them towards us.

    And please don’t get me started on the lack of quality mangers in the IT ranks…… They are the #1 reason good talent leaves organizations.

  6. While I believe that some people avoid the “software gadget culture” due to the fact that new tools create work and change (which far too many programmers are uncomfortable with), it is nice to hear a cogent argument for not using every single tool or application that the “cool kids” are using.

  7. Dave Laribee says:


    I don’t want to work with developers unwilling to work within the context of improving the whole system. I also feel I’d be a waste in a software chop shop. That is, working in a drag-and-drop, RAD-only culture is outside my interests/talents/area of expertise.

    So then there’s this reality thing. I think a lot of people that are doing the above style of work we write off. We say, “okay, there’s no talking to you.” In my experience this is not true. The change agent (person moving from low quality to high quality, optimizer, whatever) needs to be in a position to make the “this isn’t going to work out” call. This brings us back to the manager deficiency in our industry. Managers should amplify the team while aiding client pull. This means making investments in people. This means explaining rational to people. This, ultimately, means driving continuous improvement and self-empowerment.

    When you get to this (desirable) state or at least on the path (better put), small tools and practice tools are the only way to right-size a value stream.

  8. Dave,

    I see your point, and I know where you are going. But the reason that the IDE is becoming the ‘monument’ is because many developers do not have the will, the want or the time to learn many ‘small tools’.

    I am going to assume that most of the people that read this blog (and codebetter in general) are ok with the small tools, we are willing to explore new ideas, try new ways of doing things. But this is not the case for the masses. Many developers (morts as MS would call them) just want things to ‘work’. They want to come in, do their job and go home. And they want this to be painless and friction free as possible.

    It is for this reason why the IDE is becoming the ‘be all, end all’ product.

  9. Dave,

    Totally agreed. Too many times we’re seeing tools that want to be the be all end all in our tool chest. In fact, I’d say it’s nice to have choices. But, let’s be realistic. Those point tools that we talk about should be focused on its core mission and nothing more. The fact that they might integrate or play nicely is a plus, but not always necessary. Too many times we’ve seen these tools become so bloated with all of these wiz-bang gee wiz features that half the time I don’t use and most of the time get in my way.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>