Integrated Development Environment
There are a few choices here, mostly based on the language in which you are developing. Most modern IDEs provide some valuable features that allow us to us spend our time creating rather than on the more mechanical aspects of coding. There is a fine line between becoming overly dependent on the IDE and letting it support what you do, but that line is best defined individually. Some useful features that we sometimes take for granted include syntactic highlighting (Garanimals for Programmers), easy links to the debugger, and some level of code/project organization. You can still choose to write code in VI, but these features make our lives much easier on the whole. Many studies have identified that one of the biggest drains on productivity and creativity is context switching. Every time we need to leave one environment and switch to another, we have to switch context. Being able to run our application through a debugger without having to move to a separate debugging process helps us to stay in that “groove.” Similarly, visual cues like syntax highlighting and even being able to provide a rudimentary level of auto-completion gives a programmer the freedom to concentrate more on the creative process than on the basic syntax of the language. One other feature that many modern IDEs now include is a refactoring engine, which allows the IDE to do a lot of the cut, copy, and paste that is a part of many refactoring methods. Having this engine find all of the instances of a changing variable or all of the places that an extracted class might need to be used is a boon to productivity. Additionally, it makes us comfortable with creating changes that are vital to maintaining suppleness in our code.
Automated Unit Testing Framework
It is now generally accepted throughout the development community that test-driven development is a necessary and useful practice. Test-driven development (TDD) drives design toward highly cohesive, loosely coupled code. The practice also builds a certain level of quality verification into the actual code, providing that most elusive of benefits, high code coverage. Most unit test tools are based on the xUnit foundations, although there are some notable exceptions. Some IDEs actually build in the unit testing platform, allowing the programmer to create unit tests right in the same environment as the production code, whether as a plugin or as an integrated module. In this case, you should consider how easy it is to write the tests first, as opposed to generating tests from existing code.
Automated Acceptance Testing Framework
Just as automated unit tests are helpful for identifying that we are creating the intended code, automated acceptance tests help to ensure that we are creating the software that our customers are expecting. These acceptance tests are an executable expression of the requirements, or acceptance criteria, for any given story. We can confirm with the customer that the acceptance criteria are actually what the customer is looking for, and then create automated tests to ensure that the software is fulfilling those criteria.
Continuous Integration Server
The best way to maintain a low cost of change is to have very tight feedback loops. This way, we find out quickly if we are going in the right direction. We also have a smaller set of changes with which to work if we find that we have in fact gone the wrong direction. We check our tests and code into the repository continuously throughout the day, and the continuous integration server picks up the changes, builds and tests them, and reports the results. This gives us a small change set to worry about if something goes wrong and a quick warning rather than waiting for nightly—or worse, weekly—builds.
In most organizations, there are many people who are interested in the state of the development project. Sometimes they can just walk into the team room, but often they can’t. Perhaps they are not physically located in the same building, state, or even continent as the team. In some cases, they are just so overwhelmed with other work that needing to get up and go check the team room whenever they want to know how things are going is an onerous burden. Project visualization tools help you communicate where in the process things stand, which user stories are done, and where things might be blocked. They don’t replace face-to-face communication, but they create charts and graphs for visual representation and provide a transparent, distributed way to show the state of affairs. Be sure to select a tool that articulates how things are going but does not enforce a workflow; only the team can do that.
All of these tools are useful and, when utilized in concert, make the business of developing software much more effective. You can live without them, but their proper usage enhances your agility. Each supports but does not supplant your work. If you find yourself changing the way you work in order to support the tool, rather than because it makes sense development-wise, then you should re-evaluate whether the tool is right for you. Let your tools work for you, so you can focus on the “meat and potatoes” of software development.