I'm a big fan of development tools. By automating development tasks we save time and gain confidence that the tasks have been applied consistently without human error. It's important to realise that however fast and accurate a tool may be, when the task is inappropriate then the tool has just hindered you. Particularly insidious, if the tool makes doing the wrong thing easy there's an immediate (if invalid) incentive to do the wrong thing rather than take longer to perform the task correctly.

I saw this recently on a discussion board in a thread on the utility of automatic properties (syntactic sugar of which I'm personally quite fond in the right circumstances). One commenter opined that due to their Visual Studio extension of choice (which was not my beloved ReSharper but will otherwise remain nameless) automatic properties were of no benefit. Their tool allowed them to create a field and related property with getter and setter with only x keystrokes. Therefore automatic properties didn't save any time in writing the code and were hence unnecessary. This attitude causes me significant concern and it's apparent origin in a tool worries me in terms of the philosophy the tool is engendering in the developer using it.

The attitude engendered seemed to be that higher productivity resulted from the tool supporting the editing of code in less keystrokes; hence producing code faster. I believe this attitude to be fatally flawed. This may give the ability to perform certain text transforms on the source code quickly but it says nothing for maintainability of the result. Code will be read many more times than it is written; a few seconds saved in producing an inferior outcome will be entirely swallowed by additional maintenance effort over the lifetime of the software. Additionally I would suggest that if a developer is making sufficient changes that these few seconds saved in making edits add up over a work day to a significant period of time then that developer is making too many code changes and the quality of their output is likely low.

When considering the tools I use the things that give me the most value are the elements that support maintainability. ReSharper is the tool that most improves my productivity because of such features. In particular its source navigation tools vastly improve my ability to work with code by improving my ability to navigate it. These features really come into their own when working with new or unfamiliar code and are also highly useful in navigating code under construction.

ReSharper also provides significant refactoring support. The value here is in ReSharper's understanding of the codebase rather than simply applying rules against text. This is a maintenance capable feature that will work with existing code not just make adding new code faster.

There are also improvements to the text editor supplied by ReSharper and I do use a number of them. The important distinction is that they're very much a nice to have feature of the product (for me at least) and not its reason for being. I may use Ctrl-D a lot but I could survive it not being there. Take away the code navigation features and I start to really hurt.

What we see here is a difference in philosophy. On the one hand tools to make editing code as text faster are nice and may save you some typing. On the other there are tools that support development as a process and encapsulate an understanding that there is significantly more to software development than modifying strings. String modification is an important thing but it is not the only thing nor even the most important thing. This difference is something I see when working with other developers or reading blogs and forums. There appears to be a distinction, often quite sharp, between those who write code and those who develop systems. From my experience those who develop systems produce the better outcomes. It is always my aspiration to belong to the second group.

In the interests of full disclosure I will mention that I have previously trialed the unnamed product mentioned above and made a decision to select ReSharper instead. This was for two primary reasons, firstly its lack of the core features (code navigation and refactoring based on a model of the code) that give ReSharper most of its value. The second reason was that it kept making assumptions about what I was typing that were wrong. Any alleged gain in productivity would thus have been swallowed by me constantly correcting the tool. This is a matter of style, where my coding style didn't fit the tool. Others may have different opinions (I've seen some glowing reviews by well know bloggers). My trial of the tool was some time ago and its featureset may have changed significantly since then. I will not be confirming or denying if any suggested product is the tool in question.

I don't get any kind of commission from JetBrains to keep plugging ReSharper, although I wish I did. I am using a licence I won as a door prize at a .NET Community group event but I was going to pay for the upgrade anyway. (Full full disclosure: I actually won two times but gave one licence to a colleague).

This train of thought was in part prompted by this article by Charles Petzold which made me consider exactly what the reasons I use in my tool selection are.