Eating Dogfood: Team City
One of the things I first noticed about Team City is how thoughtful the features were: you can see that a build had failed, and stop it so as to not waste bandwidth. It seemed that they were actively using the product as they developed it.
JetBrains is a geeks company and we create products that we use ourselves. This makes us feel the features (as well as product’s strong and weak points). And we strive to improve the product measuring this by our own and our user’s experience. We also try to be open to our users: public issue tracker, developers in feedback loop, early access builds, etc.
We do feel that developers need to get smarter information from the tool and we bring it to them. We do feel that the CI process should be integrated into daily developer’s work: thus the IDE integration. We need the thing to be easily (re)configurable, so here is an administration UI. We need quick access to every single piece of build information from UI: so here it is. We manage our 70+ farm of build agent machines: so there are many administration-related features inside. We do branch, we do… and so on. Frankly, we have so many more ideas that the question is not _what_ to implement, but what to implement in the first place.
I’m not surprised that they use their own product, but what is interesting is the way they scratch their own itches. As a self-professed geek’s company, they are their own focus group.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)