Ayende started a thread in the ALT.NET newsgroup asking participants what practices they deemed absolutely necessary on a project. In other words, if you were to start in a shop that had none of the current “best practices” in place, which ones would you spend your political capital on trying to get into place first.
If I only had enough time, money, and political capital to accomplish seven things, I would choose the following:
- Test Driven Development: This is the one practice that I can’t really live without. I can be patient if others decide not to use it (although I will quietly try to win them over), but I would be in a real moral quandary if I wasn’t allowed to practice this myself for some reason. It enables me to capture requirements concretely, improve my design by “dog-fooding” my own API, and refactor without fear because I have at least some assurance that I haven’t broken anything.
- Source Control: I don’t really consider VSS a legitimate option, but as long as I don’t have to do much branching I can live with it in the short term (as I am doing now). At least VSS allows you to easily identify changes in a file and gives you a fair shot at rolling back individual files. No source control is simply not an option.
- Continuous Integration: The more people you have, the more necessary this becomes. The longer the feedback loop, the more pain you incur by fixing integration problems. At minimum, you need to have a controller (i.e. CruiseControl.NET) monitoring your source control system and automatically building your projects and running your unit tests (at least the fast running ones) upon check-in. Longer running tests can be scheduled hourly or nightly. Visibility (i.e. stoplight) is key if you want your team to get the most out of this practice.
- One Step Deployment: There is nothing more frustrating than having to take responsibility for deployment related errors that occurred in your application because a manual step was accidentally omitted. You may know that it was the deployment process that sucks, but everyone else will assume it is your code.
- Bug/Feature Tracking: The place I work at now uses JIRA, which is probably the best tool I’ve used so far in this category. If you can’t effectively track your work, then you have no chance of getting it done right on a consistent basis.
- Developer Productivity Tools (Resharper/CodeRush): I bought my own personal license for Resharper so I wouldn’t have be forced to go without. The more keyboard shortcuts I have at my disposal, the faster I code and the better chance I have to get and stay in the zone where I am focused just on solving the problem at hand rather than getting distracted by syntax and unnecessary keystrokes.
- Iterative SDLC: I simply refuse to work on another death-march, multi-year waterfall project. Although I think mature agile shops are by far the best working environments, I can be happy in more traditional shops as long as they follow some basic principals in spirit. Releases must be frequent and there has to be some interactive way to capture user requirements. Work should be continually re-prioritized based both on business value and according to a realistic budget based on average team velocity. Most developer overtime I witness seems to be avoidable and a direct result of the break-down in one of these fundamental practices.
If you only had seven to choose from, is there anything that you would bump off this list in favor of a practice you find more essential?
Popularity: 10% [?]
