Augmenting your IDE with Developer Tools

Download PDF Version

Why third party developer tools are important.

The question of whether or not to augment your out-of-the-box IDE with third party developer tools often leads to heated discussions. There seem to be two flavors of developers: those who work in a plain vanilla IDE (such as Visual Studio) and never install any third-party developer tools, and there are others who may install all manner of additional tools to augment their developer environment. If you’re in the former group, you may be interested to know why your peers have decided that plain vanilla isn’t good enough.

A third-party developer tool is an add-in that lives inside the host IDE and provides additional functionality – something you can’t get from the host IDE. The add-in typically offers significant improvement over existing features. There are add-ins that boost efficiency gains (more code in fewer keystrokes, refactoring tools, etc.) and increase code quality (find and fix defects, consolidate duplicated code, etc.). There are also add-ins that tighten the feedback loop (continuous testing, color swatches, etc.), allowing you to see the impact of a code change much faster than you would using the plain vanilla IDE.

If the improvement offered by the dev tool is sufficiently relevant to the developer population at large, that feature is likely to be rolled into a future version of the host IDE. So in this regard, working in an IDE loaded with the best third-party dev tools is like living in the future. Based on historical precedent, that future seems to be about 2 - 6 years away.

One reason for the time lag is the release cycle. A host IDE tends to be a behemoth of code, with hundreds of thousands of test cases that take days to run on multiple machines. Release cycles for IDEs tend to be every two-to-three years. Release cycles for add-ins tend to be every six months or less.

Another interesting comparison is response time for fixing defects and implementing suggestions. This is an area where smaller companies tend to produce more impressive results than the larger companies behind the IDEs. I know of add-in devs who have implemented feature requests within hours of receiving them and fixed bugs on the same day they were reported. To my knowledge this doesn’t happen in any other area of software development.

Because of the frequent release cycle and the highly responsive nature of developer tool vendors, early adopters have an opportunity to more directly influence the future than devs working only in a plain vanilla IDE.

There is also a competitive advantage to consider. A developer working with advanced tools can more readily find defects in code created by their plain vanilla peers. Or that developer can work much faster or think at a more abstract level, focusing more on design and implementation challenges and less on the mechanics of actually writing the code. Developers working with advanced tools tend to check-in higher quality code.

So a developer who chooses to work with third party tools is likely to be someone who values high quality code, efficiency, speed, and having control over the future. There may also be environmental aspects where a competitive advantage over peers yields important perceived benefits.

Of course, here at DevExpress we are certainly not unbiased in this issue. We make and market the best IDE productivity enhancement in the .NET developer space: CodeRush. Not only that, but we use CodeRush itself to help develop CodeRush; our development team are strong believers in the productivity gains provided by the tool, as well as the capabilities it offers to write cleaner, more understandable code, to support our testing efforts to produce quality software. Features such as code issue detection and the code duplication and consolidation mean that the CodeRush code is more stable, robust, and performant than it would otherwise be.

So what makes a plain vanilla IDE dev stay with only the out-of-the-box experience? Reasons include company policy, limited resources, or simply not knowing advanced tools are out there. If you’re a plain vanilla IDE dev and you’re interested in evaluating the benefits of early adoption, you need to understand why you aren’t using more advanced tools like CodeRush to write code, and counter appropriately and proactively (e.g., effect change to the company policy or research third-party tools).

A rich add-in market is important. The more devs you have creating add-ins for a host IDE, the greater the diversity. Diversity is an essential ingredient to producing unexpected, sometimes amazing innovation. Great innovation will almost always be incorporated into the host IDEs of the future, but that innovation is ready to be experienced today with CodeRush. The impact is this: even plain vanilla IDE devs eventually benefit from a diverse add-in market. A rich add-in market effectively crowd-sources the R&D for future versions of the host IDE, which accelerates the advancement of IDE tech. And that’s good for all of us.

Download CodeRush: Free Evaluation Version