Tools are a warm blanket

I was prompted by a blog entry from Andy Marks about tools used.
In my new role I’m looking at transforming the way that software development is performed, and I’m constantly reminded of “the old school” tools driven approach which I’ve always hated.
Putting it bluntly, tools are a warm blanket, useful only if you have a roof, 4 walls and a nice fire. If you’re out in the open, snow all around you, a warm blanket looks like it will help, but face it, you’re going to catch hypothermia and die. Without the blanket, you’re going to die faster, which is probably much better. In the case of software development (rather than my grandpa analogies) failing faster is the key. Fail fast and try again with new learnings, or succeed – failing slowly is the worst possible outcome.
A long lingering death of a software project, propped up by tools that are inadequate or inappropriate guarantees recriminations, witch hunts, and the festering “business .vs. IT” mentality that is entrenched in the corporate computing world.
So, what are we to do ? We have to always remember that its people that are the key to success. I’ll stretch that a little bit more, it’s people and their skills, not process and tools.
Where does that leave tools ? I mean, they’re useful, because it enables work to be done with greater productivity. Who doesn’t use a refactoring editor these days ? Extract method is one click away, rather than following the 8 steps in Martins book.
I was talking to my manager about this phenomenon, and I was able to articulate my view more clearly about the value of tools in software development.
“Tools should be used to automate tasks that people understand how to perform, not provide a crutch for people to perform tasks that they don’t understand.”
If the people don’t understand how to perform a task, don’t use a tool to hide it, help them learn how to perform the task first, then use the tool to automate it, make it less error prone.


5 thoughts on “Tools are a warm blanket

  1. I can use a java compiler, but I don’t know how to convert java source code into bytecode. It’s a tool that provides a layer of abstraction, which I can be ignorant of – I can get on with doing something more useful.
    Why should any other tools be treated otherwise? If I’m using a code generator tool that generates low-level JDBC code, my webservice proxy classes, etc – should I have to understand the code it produces before I am allowed to use them and be productive? Why can’t I just use these tools and get on with my writing business logic?
    At what point does a tool earn enough trust so that we can take it for granted, safe in the knowledge that it does the right thing?

  2. I can’t agree. When I started developing with C++, I didn’t know what the command line compiler and linker tools were called, and I had no idea how to actually run a build from the commandline outside of VS.NET
    Despite that, I was still able to get the process up and running using CruiseControl.NET and NAnt with the solution task.
    I still don’t know how to do a command line build for C++ under Microsoft, and frankly, I’m in no hurry to learn. I have continuous integration set up, unit tests running, and test reporting. How? By using tools…
    – VS.NET
    – NAnt
    – CruiseControl.NET
    – NUnit
    Hope the new job is going well.

  3. RE:> Mike Burke
    It’s about risk. If you don’t understand how Java source code compiles, you’re stuffed if the compiler generates broken code or you want to modify the generated code to work slightly differently. How likely is that ? What’s the impact of that ? In my Java career, #1 has happened a few times, and I’ve been eternally grateful that I understand the Java class structure each time. #2 has never happened, and I don’t anticipate that it ever will.
    The Java compiler is one type of tool. There are other types of tools such as XDoclet which auto-generates ejb descriptors. Wizards from IDEs which generate code and deployment descriptors, tools like Hibernate that generate SQL.
    In every case I’ve seen examples of people using these tools with no idea about what they are doing, and the tools generating broken code, or code which is unsuitable (for example a loop with String foo = oldFoo + bar, which I’ve seen).
    You pose the question ; “At what point does a tool earn enough trust so that we can take it for granted, safe in the knowledge that it does the right thing?”
    I would answer that with ; “When you are satisfied that the risk of using it without understanding it will not impact your project success”.
    Having an understanding of what you are doing is fundamental to managing the risks associated with software development, and understanding the risk associated with not knowing is key.

  4. RE: > Pete Hancock
    I’m not sure if that says more about the Microsoft toolset than anything else.
    However, I’ll respond briefly by asking how much easier and less error prone would it have been if you’d understood how the toolset worked ?
    Could you have been more effective at managing the process with greater information ?
    I don’t know the answers to this, but I’d be betting that in the case where things don’t work as expected, other things being equal, a person with the knowledge of the Microsoft commandline toolset will have a greater chance of fixing it faster than somebody without it.
    Oh, and pretty good thanks 😉

Comments are closed.