At the moment the programmers working on IntelliJ are in the that excellent position of being able to use their product to write their product. I would imagine that IntelliJ is written using IntelliJ, and I think this must account for some of its success. Whatever is an annoyance to IntelliJ's users will be an annoyance to its developers first, whatever makes developing the product hard or slow will make using the product hard or slow, and conversely whatever makes development easier and faster will make use easier and faster. If you can arrange it so that your software developers are also your first software users it can certainly help your product.

It's going to be interesting to see how the EJB support in IntelliJ develops. Obviously IntelliJ does not itself involve any EJBs so using and testing that functionality won't be an intimate and inescapable part of developing it. Will they be able to come up with something as good when they're not working first to please themselves?

A couple of side notes. On my recent trip to Microsoft I noticed that several developers there used emacs instead of VisualStudio.NET to develop in. Clearly this is not a good thing. If you can't convince your own internal developers to use the product it doesn't bode well for outside users. Nathaniel S. Borenstein talks about this issue, getting editor writers to use the editor they're writing, in his great book Programming as if People Mattered. Doing it by fiat doesn't work. He says you need to provide some compelling feature that the current editor doesn't provide, and can't easily be hacked in. For me and IntelliJ that was the refactoring support.

At work we don't currently use our product to develop our product but that's certainly one of our longer term goals. Certainly whenever one of the developers has to spend any time working with the product they come back with ideas they immediately want to implement to make things easier. Our JMS based debugger for debugging processes executing on the server from an authoring environment running on a client machine was the outcome of one of these ideas. The more of the tool that is build from the tool using the tool the better it will be for us and our customers.

Obviously we also need to keep in mind the main purpose of our product but the more contact the developers have with product use the better. This is the idea behind some company's system of rotating developers throught consulting/professional services from time to time, to keep them in touch with what the thing they are developing is actually being used for.