One point to note on this list; the points are just as valid for people developing by themselves as they are for teams of 20, with the exception that you will have to play the Wii by yourself (we'd recommend Zelda instead of Wii Tennis).
Spend time or money on a decent IDE
We've been developing our content management system with Intellij Idea since version 3. It is seriously good software and has definitely made the company more productive. We even have our XHTML developers using it, the editor is that good. Code completion, stubs, easily switch-able project environments, local versioning, refactoring, integrated debugging, syntax and validation highlighting, the list goes on and on.
That's not to say it is the right tool for you. If you are not writing Java, spend time looking for the best IDE that suits your needs. Read up on what's hot in your language of choice, try them out and spend time learning the feature set.
Finally, don't be an IDE fascist! If someone in the team wants to use vi or emacs, let them. It's a personal choice, and different systems work for different people. Forcing an IDE on someone is not productive. As a bonus, having vi users in your team means you get to make jokes about them wanting to escape from everything.
Simplify your development environment as much as possible
Every time your team gets a new member and every time your hard disk visits the great gig in the sky you will need to provision a new machine and get the development environment set up as soon as possible. This takes time that otherwise could be spent writing code, so it's vital to ensure that it runs as smoothly as possible. Try and get the process down to as few steps as you can, automate as much as possible, and maybe even get a disk image created with a standard build installed and ready to go.
Development environments have a habit of becoming polluted, causing you to chase your tail with bugs that don't actually exist in your code, but are instead caused by a dodgy environment. You want to reduce this from occurring as often as possible. If you can hose your machine and rebuild it in 30 minutes, you will get a decent productivity increase in the long term.
It's also important to be able to spot these "phantom bugs" so that you can mitigate their effects as early as possible. Chasing an environment bug is no fun at all.
Learn all the features of your debugger
One of the reasons we like Java is the level of debugger support that it provides. Breakpoints, evaluation of expressions during runtime, being able to examine a graph of objects in memory at a single point in execution time are king in our opinion. Writing log statements every couple of lines is a waste of resources and clutters your code with rubbish.
Learn all the aspects of your debugger. Chances are that if you have been thinking "wouldn't it be great if I could do this" with the debugger, you probably can, you just don't know how to. If you can't, it might be time to look for a new IDE.
Perform 1 click builds
If you can't create a new build of your application by performing one discrete action, stop everything and get to a point where you can. We use Ant (and now Maven 2) to perform these tasks, in association with some simple bash scripts, but there are a number of different ways of achieving this goal.
Being able to create builds quickly, easily and reliably is crucially important. Chasing phantom bugs that are actually a result of a bad build can wipe days off your productivity, if you are not careful.
Being able to roll a new build and deploy it quickly will speed up your develop/build/test cycle. If you're sat around for 30 minutes waiting for your build manager to put the final tweaks to a build, you are killing time and inviting error.
Spend time selecting your frameworks, and don't be afraid of making brave choices
Just because everyone in the world is using Struts, Spring and Hibernate to write their applications doesn't mean that you should too. Choosing the right frameworks for your project is not a simple task. Time spent now will reap rewards later down the line. Take time to get a shortlist together, looking out for decent blogs, email lists and framework vendor websites to see what is out there.
Once you have a shortlist together, put aside a few days to try each one out. If things don't survive 30 minutes of development without obvious signs of productivity increases, put them to one side and try the next one. Don't forget the value of good documentation as well as the size and quality of the user and developer community.
We're currently evaluating Wicket, Stripes and Ruby on Rails as potential candidates when the appropriate project comes along. Remember, use the right tool for the job and try not to get stuck in a rut of using the same tools over and over again. That makes development boring, as discussed in my next point!
Get your developers excited about developing again
It's easy to forget that writing the same 15 basic use cases over and over again for different applications using the same language and frameworks gets pretty boring, pretty quickly. Developers can fall into rote development methods quite easily. While there's nothing wrong with this, it can be just as important getting your developers enthused about developing again.
How to do this? Swap out one of your frameworks, change developer roles, or even implement another language. Java developers can now write in a number of different languages that result in Java bytecode that will be 100% compatible with the rest of the application. Start writing some tests in Groovy, or JRuby. Make use of Velocity or Freemarker on the templating side. Anything to break from the norm and introduce some different concepts can be a good thing.
Automate your web testing as much as possible, but don't rely on automation
Using tools like Selenium or Canoo can be a real time saver. We tend to believe that, pragmatically, web testing is more beneficial to a project than unit testing. That's not to say that you shouldn't write unit tests, but they simply don't put as much code under the microscope as a good set of web tests do. Selenium can also be a great way of testing different browser platforms.
Having said all that, it's important not to rely on web tests as a silver bullet. Selenium isn't perfect, and it certainly can't beat a good set of eyes looking for bugs. Automated testing is also only as good as the tests that have been written.
In our experience, the best application tester, by a long way, is someone that has never seen the application before. They won't know what to expect, or how things work. Just watching someone with no knowledge of the application trying to use it can be as revealing as a dozen good web tests.
Find a decent bug tracker
No, email is not a bug tracker! Build, buy or grab an open source bug tracker and use it religiously. We use Jira, which is frankly superb, but the open source Mantis is also pretty damn good. There are a myriad of reasons to use a bug tracker; assigning work to developers, tracking their progress, building a resource of information for people working the project and so on.
Remember that bug trackers don't just have to track bugs. Minor functionality upgrades and associated tasks are perfectly suited to the bug tracker process.
Use a Wiki
There's more chance of Google merging with Microsoft than there is of your developers opening a copy of Word and writing some documentation without being forced to. Accept this as reality, and instead provide them with tools that they can use easily and in an unstructured fashion. Grab a wiki (there are a load of free ones available as well as some good commercial solutions), stick it on a Dev server somewhere and your developers WILL start using it.
Wikis are unstructured, and we think that's a good thing. Documenting important, unrelated pieces of information as you go tends to be an unstructured process.
Buy a Wii (really!)
No, this is not a joke, and this point wasn't added in to make up the numbers (probably because it's point 11). It's all too easy to fall into the trap of working non-stop, huddled over your keyboard until you need to eat or sleep. The more a deadline looms into view, the more it feels like this is the only option available. Every second counts, right? Well, yes of course it does, but in our experience spending every second hacking code is not the most productive way of doing things.
We bought a Wii a few months ago (OK! It looked like fun and we didn't originally buy it for this reason) and have been amazed at the effect it has had in our office. Every couple of hours we will FORCE PEOPLE to play tennis for 15 minutes.
Not only will it get you out of your seat and doing something physical (this is really, really important), but it is a great way to clear the mind of crap and generally de-stress. Pissed off with your colleague for checking in some code that breaks your build? Serve them up a couple of 110 mph aces on the court and you won't start screaming at them the next time they do it.
It's a great way to build a strong, happy team.
