Let me just say this, to start: I’m a big fan of good, functional, effective software development tools. On the flip side, I can’t stand being forced to work with a tool that makes it harder for me to work. Where I am now, I do Java EE development with Struts; I have a few tools that make this easier (and a few which do nothing to help).
A good software tool doesn’t get in your way, does what you expect it to do, and makes it easier to do common tasks, which allows you to be more relaxed, focus more, get more done faster, and in the end, create better software. In other words, it makes software development not suck. A bad tool, on the other hand, does the opposite; it takes too long to run, or it gets in the way, or you can’t quite tell if you’re supposed to be using it the way you do, or whatever. It just makes software development suck more than it should. Developers shouldn’t have to fight with their tools just to make good software; their tools should help them by conforming to their concept of what should be done, and never surprising them.
I think this is the most important part; being surprised when using a tool is dangerous. An unpleasant surprise, like a crash, files being deleted, or something taking a long time to finish, leads to grumpiness, frustration, lack of focus, and potential damage to the software itself. Pleasant surprises, on the other hand, are even scarier; they indicate that you’ve grown comfortable with using a shitty tool, or that you haven’t been using the tool correctly in the past. If you ever find yourself pleasantly surprised at something you use daily, then it’s probably time to look for a replacement for it.
Here’s the list of tools I’m using now (or wish I could be using):
One of my favorite tools overall right now is Trello, the web-based task management software. Since I do rapid development on a number of concurrent issues, I use Trello to keep track of what I’m working on down to a fine level of granularity.
I know this is slightly outside the norm for most software developers, but I use Trello like so:
- Boards = Issues (our equivalent of bugs/tickets/RFCs in our in-house issue tracker)
- Lists = Kanban-style stages of completion (Todo, Doing, Done, On Hold)
- Cards = Small tasks/objectives (“Deploy to X site”, “Code Review”, etc.)
In addition, I make extensive use of Trello’s checklist functionality to keep track of changed files across multiple projects, track what files need to be deployed in our (horrendously backwards) manual deployment procedure, and for larger projects, to track what specific changes I’m making, and whether or not I’ve coded them up. It’s become an indispensable part of my toolkit, and I can’t imagine going without it.
As for bug tracking, I’m a bit stuck right now. There is no common process for tracking bugs at my work; we’re expected to open issues to resolve them using our internal issue tracker, and I’m honestly not too happy about that.
However, the best bug tracker I’ve used has been Trac, and the best bug tracker I’ve seen has been either Github, Bugzilla, or JIRA. Trac, for me, is flexible and familiar; I’ve used it before for a year-long project through my school, and it’s a serviceable bug tracker with some nifty tools, although the interface design leaves a lot to be desired. Bugzilla is the first bug tracker I’ve ever seen (because of Firefox bugs way before I became a developer), and it makes sense for me to see bugs laid out like that. Github’s issue-tracking utilities are what I wish I had available to me now, for my own projects, but I can’t really use it with my current projects. JIRA adds another layer on top of that, providing the Kanban board layout I’m used to creating manually in Trello, but directly integrated into the bug tracker.
Right now, I use SlimTimer for time tracking. It’s simple, sticks on the desktop in a slim browser window, and lets you add tasks, switch rapidly between different tasks, and resolve and remove tasks in a minimal number of clicks. Editing entries is fairly easy (including obvious shortcuts, like entering “now” or “4p” into a time field) and generating a report is pretty straightforward (if annoyingly time-consuming). The only complaint I have with it is that the site itself crashes occasionally, and it takes forever to come back up. (NOTE: That might have something to do with the firewall at my work, but I kind of doubt it.)
Let’s get something straight: I don’t usually like UML. I used to waste valuable time drawing something out in UML only to find that the project requirements make me have to go back and change it. Currently, I use… OpenOffice.org Draw.
Honestly, as long as something can let me draw auto-shapes and connectors, I can use it to draw UML to illustrate a point. And that’s all I use UML for, anyway. That being said, if you’re using UML regularly on large-scale designs, then whatever tool you use MUST have reverse-engineering and forward-engineering capabilities; that is, it must be able to convert code to UML diagrams, and convert UML diagrams to code. The best tool I’ve used for this has been Enterprise Architect; however, it’s way too bulky (and expensive!) for most situations.
My favorite version control system by far (as reflected by the entire programming community at large) is split between Git and Mercurial. I’ve used a number of version control systems throughout my career as a software developer: Git, Mercurial, Subversion, CVS (ugh), and Microsoft Visual SourceSafe (double ugh), and all I can say is that having bad version control is almost as bad as having none at all. I’ve used Mercurial more than Git, and I like its interface and performance specs slightly more, but I like the Github community that comes effectively packaged with Git, and the nice tools that it provides. Right now (unfortunately), I’m using CVS for work and (fortunately) Git for personal stuff.
Ah yes, the IDE, the number-one most-used tool by programmers. Well, most programmers. Notice, I said “programmers”, not “software developers”. Honestly, the tool I use the most is my Web browser; between project tracking, recording requirements, and testing Web pages, I use Chrome more than anything else. But when I’m not using Chrome, I’m using Eclipse.
I’ve used Eclipse since I started college in 2009, and every company I’ve worked for that develops in Java uses Eclipse. Honestly, I hate the damn thing, but I have a few addons that make it tolerable. If I had my choice of IDE to use on any and every language, I’d have to choose Microsoft Visual Studio, and add on that language’s equivalent of ReSharper. If I even had my choice of IDE to use for Java, I’d use IntelliJ IDEA, just because I’m such a huge fan of JetBrains and ReSharper.
Since I develop mostly in Java EE, my main testing tools are JUnit 4 and Selenium WebDriver, but that’s mostly because I haven’t gotten around to messing with TestNG just yet. I also make use of a number of browser-specific Web developer tools, such as Chrome’s built-in Developer Tools, Firefox’s Firebug, EditThisCookie for Chrome and FF, and the Google Analytics plugin for Chrome. I’ve been told to look into Greasemonkey, but I haven’t dabbled in it yet.
The only CI tool I’ve used is Jenkins. It worked exactly as it should, building projects nightly and yelling at whoever broke the build. Oddly enough, I haven’t used any other continuous integration toolkits professionally; I blame this on working for small companies which don’t feel the need for continuous integration and automated deployment. I’ve been told that CruiseControl and its offshoots are better, but I haven’t had a chance to explore them yet.
I use Araxis Merge and KDiff3, mostly because they fill the gaps not covered by IDE-provided diff tools (like Eclipse’s Comparison window) or online diff tools (like Github’s commit page). Araxis is nice, but I’m stuck using the 2008 version at work, and it really shows in the UI.