The Busy Manager’s Guide to Development Tools
As with nearly all domains, particularly of a technical nature, my line of work is full of buzzwords and arcane tools and concepts. While I’m primarily a developer, I often have contact with less technical personnel at my clients. Often I perceive a need for an executive-level overview of some of the tools and concepts we developers use on a daily basis, and so in this post I’ll introduce some of them. If you discover something missing from the list, I invite you to post a comment.
Version Control System
Use of a Version Control System (VCS), sometimes called SCM or Source Code Management (and sometimes Source Configuration Management, though that is really a larger topic), is one of the most basic practices of a development team. A Version Control System is a tool for sharing code across a team of developers. It will typically consist of a central server to which all the developers sync their systems to retrieve and commit code. The Version Control System keeps track of revisions and can assist in tracking and merging parallel streams of development effort.
Historically, CVS was the standard Version Control System tool. In recent years most CVS users have moved to Subversion, which improves on it in a number of respects. See my earlier post, An Introduction to Subversion for more information. Recently a new paradigm, Distributed Version Control has been developing a following, with Git and Mercurial being particularly popular Version Control System tools.
Integrated Development Environment
Historically, code was written by a developer using a text editor. The editors popular with developers tended to be more powerful than Notepad, for instance, but they were still basically text editors. An Integrated Development Environment (IDE), on the other hand, adds numerous other capabilities such as refactoring tools, integrated debugging, Version Control System support, and many project management capabilities.
In the Java world Eclipse, which is free and open-source, is the most used Integrated Development Environment with IntelliJ IDEA being a popular commercial offering. Microsoft’s entry in this space, meanwhile, is Visual Studio.
Note that while this paragraph has the appearance of objectivity, proponents of the aforementioned text editors would consider my characterization of Integrated Development Environments as superior to text editors for development of code to be an affront, though possibly not as great an affront as my associating their favored tool with Notepad.
JUnit
An important component of developing a robust, high-quality application is the ability to prove that it does what it is supposed to do and that this fact doesn’t change when new code is committed. The best way to do this is with unit tests. Unit tests are written in code and tested against the production code.
In Java, the most popular library for assisting in writing unit tests in JUnit. JUnit provides utility methods for asserting that the state of an application is as expected. Typically, a unit test would set up a condition to be tested, then test that the condition is indeed true, then revert any affected resources to a known state. A failure at any point would result in an error pointing at the flawed code. JUnit tests can typically be run within Integrated Development Environments at development time or in an automated fashion when code is checked into a Version Control System (see the section on Continuous Integration later in this post).
An ancillary concept here is Test Driven Development (TDD), a practice in which unit tests are written before writing the code under test to help drive the development of the architecture of the code and its structure, as well as to ensure newly written code is fully tested.
Ant
Before the introduction of Apache Ant, building Java projects involved ad hoc tools that often weren’t consistent across operating systems and environments. Ant is an open-source XML-based build scripting tool that is easily extensible. Ant allows a development team to script the compilation, assembly, and deployment of their application. This simplifies development across heterogeneous operating systems as well as the automation of important development tasks.
Ant has the downside that it must be kept in sync with an Integrated Development Environment’s own project configuration (usually a proprietary format). As well, Ant scripts can become quite complex for some applications, with the code essentially becoming another form of code to maintain.
Maven
Also a product of the Apache Foundation, Apache Maven is an alternative to Ant, and a very different approach to the problem. It uses convention and configuration, rather than scripting, to perform the build, assembly, and deployment capabilities that Ant provides. This is a subtle distinction. Maven is much less like a programming language than Ant and instead provides a declaration of a project’s structure and capabilities.
Though its learning curve is a bit steeper than Ant it is, in my opinion, usually the better choice as a build tool, particularly for complex projects. While Ant requires that every step in a build be scripted, Maven typically requires minimal configuration for a simple project and manages interdependencies between projects with aplomb.
A key factor to Maven’s added value is its provision of a central repository of libraries, which it can download on demand. Thus, a project can declare dependencies on many artifacts without requiring team members to individually browse the Web, download, and install the many components typically required for a modern, complex, Java application.
Continuous Integration
Writing high-quality code is important. Checking it into a regularly backed-up version control system is vital. I believe writing and running unit tests is also essential to ensuring a quality product. The component in the suite of developer tools that brings these all together is Continuous Integration (CI). Continuous Integration is the practice of automatically running a full build, test, and (optionally) deploy cycle regularly–preferably every time code is checked into the Version Control System. Historically Cruise Control and CruiseControl.NET were popular options but the past year has seen Hudson take over as the free Continuous Integration system of choice.
How does Continuous Integration work? Typically a Continuous Integration system is configured to monitor a Version Control System. When it detects that a check-in has occurred, it obtains the latest version of the code, performs a build, runs unit tests, and reports on the results. It can be configured to e-mail developers when a build breaks or tests fail. Continuous Integration systems are usually extensible and have many plugins and integration mechanisms. In my case, I have a large stoplight on my desk that’s green when a build is successful, yellow when it’s in process, and red if the build fails.
I was on a recent project that took rather too long to get its Continuous Integration system set up correctly due to an unexplored error. When we finally fixed the error, our team velocity immediately shot up. Because the team knew within moments after check-in that the entire application built correctly and passed its tests, we could spend less time running unit tests manually and we were confident the code would work for our peers. Additionally, quality increased because we could afford to be more daring in our refactorings. In my experience, the effective use of Continuous Integration is absolutely vital to any high performance development team.
I’m interested to hear of other tools requiring explanation. I have seen many situations in which well-meaning managers questioned the time a development team spent maintaining their infrastructure and tending to their tools. Having experienced the velocity increase when everything works, however, I’m a big proponent of spending that time getting it right. It is vital to the success of a development team that they become experts in their infrastructure and its tools. Spending the time in self-training will more than pay off in gained productivity and quality over time.
Tags: ant, continuous integration, hudson, tools
March 12th, 2009 at 8:01 pm
That is a great primer on state of the art development tools. There are lots of other tools and I’d like to mention one that is so obvious that you forgot to mention it (if it had been a snake – it would have bitten you).
JavaDoc – the code documentation tool of choice.
The inventors of Java decide to build a code documentation tool right into the language, or right along side it anyway. And what a great idea that was!
JavaDoc makes it so easy to document the Application Programmer’s Interface (API) of the code you are writing now that 80% of developer actually _do_ document their API! Compared to 20% in the old days – that’s a huge improvement.
You may think this is not very important (just let them read code – to paraphrase Marie-Antoinette) but if the developer’s know what your code should do, then they can better maintain and improve the code base. If your code base doesn’t have it’s own JavaDocs you should question why!
March 12th, 2009 at 10:38 pm
An interesting suggestion, David. I would probably put JavaDocs in the category of communication tools rather than development tools (along with wikis, for instance), but a solid argument could probably be made for their inclusion in my list.
I’m going to disagree with you in suggesting that all code should have JavaDocs, however. I’m in the camp that believes code should be self-documenting (test code counts as documentation). In my observation when developers spend a lot of time writing JavaDocs they are spending less time writing code and they become resistant to refactoring due to the additional time cost of updating the documentation. Code written using TDD, though, would see the documentation (all uses of the code in question, including the tests) updated as the API changes. Therefore there’s no additional cost beyond the code changes that would occur in any case.
Code that will be consumed by another development team, however should have JavaDocs–at least the public API should. I imagine this topic is worthy of a blog post of its own, though I’m not certain I’m ready to be that inflammatory in this forum…