It was a long time ago that he wrote it, but only recently that I read Mark Seemann’s thoughts in a well-written and thoughtful post called Beware of Productivity Tools. In it, he made some really good points about why tools such as ReSharper don’t provide the immense value claimed by devoted adherents and why he chooses not to use them. Mark’s devotion to helping others on stackoverflow.com, his blog, conferences, and in other media make him and incredible asset to the community. His recent appearance on the best geek podcast in the Universe was an excellent exploration of a topic very near and dear to me: flow. I appreciate his candor in addressing his position on these tools. As a user and a fan of ReSharper (ok, I have to admit it: a BIG, slobbering, zealot for ReSharper), I want to provide a bit of a counterpoint to his arguments and present why I think ReSharper is not only worth using, but also worth the pricetag. In short, I want to defend productivity tools.
I do not intend to try to convince Mark or anyone else that they are doing it wrong if they don’t use a particular tool. I do, though, recognize that we can all do better than we are currently doing and there are many tools that aid in doing so. If I come across a person using a fork to eat a bowl of broth and they are unaware that there’s a better tool for the job, it wouldn’t be very neighborly of me to withhold that knowledge. There is a fine line and a delicate balance between being a helpful advocate with useful advice and being an annoyance pushing a product. It appears Mark has tried ReSharper and doesn’t find it to his liking. Fair enough and case closed. I will not be trying to push him in any direction. When I sit down to pair program with someone, though, and they are launching the NUnit user interface and hunting for their assemblies to load into it or scrolling their Solution Explorer in Visual Studio when they want to open a class, it would be silly and unproductive not to point out that there’s a better way. It may be that my pair is not interested or won’t go to the effort to learn the tool. It may even be that this person is offended that I made a suggestion for a way to do things better. I believe that such a person is misguided. If you point out a tool or a better way of doing something to me and it can help me to improve, my response is gratitude.
So what did Mark Seemann really say?
In case you don’t want to read his whole blog post or you just want my overly exaggerated interpretation, here is a summary of the points he presented:
- I don’t like ReSharper, so get off my back.
- Productivity tools force you to write code in a specific way and are therefore bad.
- Keyboarding speed is not the bottleneck in development and productivity tools can only possibly boost productivity by increasing your keyboarding speed.
To address these points, one at a time:
I don’t like ReSharper, so get off my back.
This is the point on which I find the most agreement with Mark – it’s a personal choice and he doesn’t have to like it. Please, get off his back. I’ll talk about why I like productivity tools, especially ReSharper, when and where it’s a topic that comes up, but I’ll not be trying to push anyone who doesn’t want it. I think everyone would be better of if they eat a lot of butter, but I’m happy doing it myself, telling people who care, and letting everyone else do what they think is best. Live and let live is always the best policy. If somebody wants advice, they will usually ask for it.
Productivity tools force you to write code in a specific way and are therefore bad
There are two sides to my thoughts on this assertion. One is to say “no, they don’t” and the other is to say “yes, they do… and that can be a good thing.” Let me elaborate:
“No, they don’t”
Mark cited the timeless post by Charles Petzold entitled Does Visual Studio Rot the Mind? as evidence of the way Visual Studio forces a style of programming, Charles cites Intellisense as the strong arm that pushes you into doing top0
And yet, IntelliSense is also dictating the way we program.
For example, for many years programmers have debated whether it’s best to code in a top-down manner, where you basically start with the overall structure of the program and then eventually code the more detailed routines at the bottom; or, alternatively, the bottom-up approach, where you start with the low-level functions and then proceed upwards. Some languages, such as classical Pascal, basically impose a bottom-up approach, but other languages do not.
Well, the debate is now over. In order to get IntelliSense to work correctly, bottom-up programming is best. IntelliSense wants every class, every method, every property, every field, every method parameter, every local variable properly defined before you refer to it. If that’s not the case, then IntelliSense will try to correct what you’re typing by using something that has been defined, and which is probably just plain wrong.
There is something to this argument and it’s not just plain wrong, but it’s hyperbole. If a developer wants to key the name of a method that doesn’t exist, there is nothing stopping that and never has been. Visual Studio can be used as a text editor with a conveniently included compiler if that is its desired use for a given user. The enormous configurability of Visual Studio lets you use it however you see fit. It even has a configuration setting for turning off Intellisense if you don’t want it.
As creators of software and crafters of user experiences, we should all be aware that not every user is the same, every user has their own preferences, and most users will use our software in ways we never anticipated. The many configuration options of Visual Studio, though daunting and so plentiful as to be undiscoverable and painful with which to deal, are a superb example of letting users have it their way and use the software in a gigantic array of different styles. ReSharper is also packed with configuration options (and better organized and easier to find than Visual Studio). There is no force in what Visual Studio is doing. Even without touching configuration, Intellisense offers suggestions and leaves you free to key what you want. Yes, if what you key to completion is a match for something in the list (usually not the case when you key to completion, but certainly possible), it will autocomplete in an undesired way. The escape key is an easy remedy for that, though. This is a common complaint about the completion of modern mobile devices, yet I don’t hear many arguments for turning that off.
Additionally, refactoring support in Visual Studio and ReSharper (ReSharper’s refactoring, like most of the features ReSharper has in common with Visual Studio, is an improvement over what is there and existed before Visual Studio had it) enable the keying of the method name in the code calling the method (hopefully a test) and then using refactoring to generate the method. I understand that when Charles gave his talk and wrote the post, Visual Studio didn’t have the refactoring feature (at least not in the form it has now), so his point had more merit then. Resharper did have it then, though, which is a point in favor of using ReSharper. You were going to key the method name in one place or another and Visual Studio and ReSharper make it really easy for you to choose to key it at the point of usage and then generate a skeleton to make it compile – a skeleton that throws a NotImplementedException, which makes it really simple to continue writing your test code and have your test fail and easy to see where you need to go in your implementation to make it pass when you are ready. Visual Studio makes it very easy to choose whether you want top-down or bottom-up and forces nothing.
“Yes, they do… and that can be a good thing.”
Mark cites the Ruby on Rails community as being one that boasts enormous productivity. It’s true that they make that claim and in many ways, it is a claim that is justified. Mark didn’t go any further, though, on why that is. The expressiveness of the Ruby language is a part of the reason for that, but another (and bigger) is the tools used by that community and the mentality of the developers that aligns with the goals of the tools. Rails is an extremely opinionated framework that makes it really fast to do things the way Rails wants you to do them. If you write software the “right” way and like using Active Record, frameworks like Rails and tools like Gems, Rake, Cucumber, Capybara, and Sinatra take away a lot of the friction of the development process. It’s the tooling and convention over configuration that makes it so nice to work there. If Visual Studio makes it really easy to do software one way, that doesn’t mean it’s shutting the door on another way. In some cases it might make it harder to do things certain ways. Usually, it just means one path is made easier and another path is not changed. Using tools outside Visual Studio is certainly worthy of encouragement. Knowing how to use a command line is, in my opinion, core competency for developers (though it is woefully lacking among .NET centric folks). This does not mean, though, that using Visual Studio should be considered harmful. Citing Ruby on Rails is more counterpoint to Mark’s argument than it is supporting evidence.
Keyboarding speed is not the bottleneck in development and productivity tools can only possibly boost productivity by increasing your keyboarding speed.
I will gladly agree to point that the speed of getting something from fingers to text file is not critical (though having worked with some individuals unable to touch-type, there is a limit to the truth of this). Keyboarding is not the long pull in a software development exercise. The thought and design that go into crafting specifications and tests that express the intent of the software and writing code to bring those to life (and thereby turn them green) are the low-hanging fruit of productivity enhancement. Mark is correct in this and I have no argument. I do, though disagree with the thinking that it’s only in improving keyboarding speed that productivity tools help. ReSharper makes the life of the developer much easier by providing capabilities like a superb test runner, refactoring to make coding in a top-down manner simple, the ability to open a type or file without having to think, mind-blowingly sophisticated search capabilities, upgraded snippet support relative to Visual Studio, and a much less cumbersome interface for adding types. Of course, it has a lot more features that those, but those, to me, are the ones that make it worth the price (in dollars (or Euros or whatever) and in the time spent learning the tool). As I started using ReSharper many years and versions ago, most of these are things that Visual Studio has now but didn’t when I started. Using Visual Studio without ReSharper is a much easier sell to me now than it was with Visual Studio 2005. Still, in most cases, the ReSharper implementation is superior.
The common theme, to me, in the features of ReSharper (and Visual Studio without Resharper) that make life better, is that they reduce friction in trying to do something. It’s not about being milliseconds faster in keying a class name, it’s about not having to spend cycles in my mind thinking about having to tab through multiple fields on the add dialog to be able to choose to add a Javascript file or a C# class. Those cycles that are spent on thinking about things that aren’t the core problem are distractions that take me away from the flow state that makes badass programming possible. Those distractions compete with my real work for the processing of my mind. It’s about a test runner that works the way I expect and has state that makes sense to me. It’s about using ctrl+T to open up a class and finding it with ease because of the special search (it hurts when I watch someone scrolling though Solution Explorer). Sure, popping open a file in Vim or Emacs from a command line is also a frictionless way of opening up a class. It’s about making fewer mistakes I later have to hunt down. I have had many experiences using text editors for coding where a test is failing and everything looks right and only after a lot of head banging do I realize the problem was a difference in case my eyes just didn’t notice in staring at the thing. Avoiding this is a serious performance enhancement.
I would not claim ReSharper makes me 50% more productive and I agree with Mark in that it’s nearly impossible to measure such a thing. What I do know is that tools are useful for productivity if they do one thing: help me to think about the problem for which I am writing the code instead of thinking about the code and the tools. Visual Studio and ReSharper do that for me by helping the mechanics of coding get out of the way.