Setting up a new Java development shop

Question

I\'m setting up a Java development shop, currently just for myself as the only developer, but with hopes of needing to hire others as the business grows. Obviously I\'m hoping

Answer 1

To see what a big amount of people thinks to make a good software development environment read this article on the 12 points of joels test

This list does not include the things more important for you. Getting clients getting them to pay and manage legal stuff and taxes.

Answer 2

I like Hudson for Continuous Integration builds, and I like JIRA for issue tracking. Eclipse has plugins for both.

Hudson can watch software repositories and rebuild those projects that use the changed resources.

If you need more documentation than javadoc can cover (which is quite a lot) then consider a Wiki. Easy to use, and with a bit of structure you can massage it into a PDF.

Source control is a bugger. Too many to choose from. For a small development team start with either subversion or CVS (which is old but has supreme IDE support) and when you outgrow that and know your needs, then migrate to a better one. Most have migration tools from svn or cvs. It is harder to move from e.g. git to Mercurial, and you defintively want one with more than one implementation. Remember to have good backups of the source control repository - it IS your business. Frequent rsyncs, often tapes.

---

EDIT: You also want decent hardware. For the Continuous Integration server, the fastest build machine you can afford. For yourself the largest monitor you can afford (not in size, in resolution) for your primary monitor and as many extra monitors as you can afford to have (including adapters to your computer). I have found that Mac's use the pixels better than Windows, so that might also be a point.

My primary monitor is pivoted 90 degrees. This allows me to see many lines at once instead of a few long lines. (For some reason tradition says that editing areas should be wide and short, which may work in word but not in code where lines should not be wider than 72 characters)

Note on Eclipse: Use the source repository to have a single workspace per project! Use the Java Editor Save Function to reformat your code everytime you save - this makes it more readable up front, and goes better with the source repository as changes are marked in the correct version.

---

Edit: The reason for the CI server needing to be better than your development machine is because it will run all your tests every time you check stuff into your source repository. After a while, that WILL take time.

Personally I have found tests working well for library routines. They specify what works and what doesn't. It is harder to write good tests for whole applications, but you may want to look into that from the beginning, as it allows you to ensure that everything works for every check in. Write a comment if you are not familiar with the concept.

Whatever you choose for the individual parts, you will be glad if they can work together. Hudson knows how to talk to JIRA for instance. JIRA knows how to look in CVS.

Answer 3

We have been using:

version control:

• subversion - Its not distributed but it is accessible over a few different protocols if firewalls are an issue. I'm not sure if distributed version control is necessary for us and reading Eric Sink's take is entertaining at least

issue tracking :

• Fogbugz - You get some team discussion and communication for free with it because of the built-in wiki and discussion boards.

continuous integration:

• CruiseControl - we had been talking about switching to Hudson, but Cruise is working really well right now - it runs our unit tests.

dev environment:

• Netbeans and Eclipse - There is really no reason to pay for a Java IDE. An import point for getting going fast is that Netbeans and Eclipse both store all of their project data as text files which version control nicely. See this question. We had giant headaches when using an IDE which used binary project files.

profiler:

• JDK VisualVM - Its free and it works. I used to really like YourKit, but VisualVM does so much now.

documention:

• Combination of javadoc and fogbugz wiki pages plus the cruise dashboard for internal. For external we are using RoboHelp and we dislike it.

other tools:

• Findbugs - huge help in catching things that are sometimes really stupid and sometimes amazing quirks that you'd have never realized. PMD is good for some of this as well.
• We find chat tools to be really helpful for communication. We used to have access to Sametime and it had a giant conferencing feature that was really great. That was taken away for an unknown reason by the overlords though.

Answer 4

Here is what development stack our team of five developers is using over a year now:

• Eclipse IDE (worked better for us than NetBeans)
• Maven as a project comprehension and build tool -- simply a must tool!
• Nexus: The Maven Repository Manager -- serves as a local Maven repo for proxying, and for managing internal and 3rd party libs; simple in use and is really necessary if you're going to use Maven
• Subversion for source versioning -- was chosen mainly due to very good IDE support (Subclipse for Eclipse IDE)
• Trac as a bug tracking and requirement management tool -- it nicely integrates with Subversion, has very useful plugins including blog and discussion plugins; also it can be integrated with Eclipse Mylyn.
• Hudson as continuous integration, which nicely integrates with Subversion, Maven and Trac -- very valuable even for a small team.
• Sonar code quality management platform -- a tool which integrates a large number of code quality matrix with intuitive web interface supporting code review and drill-down facility for analysis of the problems; integrates with Maven.

In our case this development stack is running under Ubuntu (workstation components: Eclipse IDE, Maven) and CentOS (server components: Maven, Nexus, Subversion, Trac, Hudson, Sonar).

As for the documentation, LaTeX (TexLive and Kile under Ubuntu) works just great supporting high quality PDF generation. The documentation source can be managed by Subversion the same way as the application source. Allows making of simple several page document and large multi-chapter books.

Hope this helps.

Answer 5

Distributed source code/revision control (Subversion?)

• Subversion is good enough unless you want to use this as an opportunity to learn Git or Mercurial.

Bug tracking (does Trac do this?)

• Trac works fine if you don't mind CamelCaseTurningIntoWikiWords. JIRA is fancier but (as noted) not free, and I find its data-ink ratio annoyingly low. Good once you learn which parts of the UI to ignore, though.

documentation (both internal and customer facing)

• Internally, I would prefer communication over documentation unless you're really willing to commit to spending time keeping internal documentation updated. Javadoc your integration points (internal/external APIs), but try to keep your code and build scripts as self-documenting as you can.

• That said, requirements docs are useful. I'd suggest using one tracking system for bugs and requirements. JIRA lets you create hierarchical issues, but I wouldn't bother with that till you need it.

• Trac includes a Wiki, which can be handy although too much content will get stale.

• Customer-facing docs are all over the map -- depends a lot on what you're doing. If you need big fat manuals (either printed or HTML or on-line help) FrameMaker + the DITA Open Toolkit is a nice combo, but a FrameMaker license is going to set you back $1000.

• At a certain point this shades into corporate communications (marcom and PR), which are kind of a different animal.

team communication

• Google Talk (or the instant messaging framework of your choice), email, and the occasional Skype teleconference are probably all you need.

• An internal wiki and/or internal blogs might be nice but you probably don't need them right away, even once you've added a few more developers. Trac includes a wiki.

frequent automated building

• Switching from CruiseControl to Hudson has made everyone here much happier -- two teams made the same decision independently and both are pleased with it. Hudson's flexible, easy to configure, and shiny.

• I have yet to be convinced by Maven. I suspect its value depends on how much you want automated downloads of the latest versions of all your open-source libraries.

  • Edited (Feb. 2010) to add: Several months of Maven 2 experience now and I'm still not convinced. I think (like many frameworks, e.g. Rails) it may work well if you're starting from scratch and structuring your project according to its conventions, but if you already have your own structure in place it's a lot less advantageous.

maybe something to make sure automatic tests pass as part of the check-in process?

• I'd advise against it. Most of the time the tests will be passing (or should be, anyway) As long as continuous integration notifies you quickly of failures, and you also have stable automated builds (a couple of days' worth of nightly builds, tagged iteration builds, etc.), you want more and faster checkins, not fewer and slower.

Answer 6

Most important, the right staff:

• get great people who find work and handle customers (aka sales)
• get software engineers who are smart and get things done (http://www.joelonsoftware.com/items/2007/06/05.html)
• get someone who knows about accounting and the local legal and tax regulations, so you don't get any surprises

Tools / Processes:

• use a distributed version control system like git or mercurial
• jira or the like for bug/issue tracking
• continuous integration with hudson or cruisecontrol
• wiki system to share the teams tangible knowledge
• unit tests, clover, checkstyle, findbugs, ...

From a managerial point of view i would try

• daily standup meetings (checkout scrum) to keep the team updated members to commit by saying what the did, do, and will do
• timeboxed meetings, everything else sucks.
• plan iterations/sprints
• let team do task time estimations
• pair programming (gets you better code)
• code reviews (builds trust)
• weekly in house "techtalks" to build a strong sense for the team
• twitter like communication tool to keep all insync and informed with minimal distraction
• develop team towards dynamic languages (groovy, scala, ...)
• yourself, listen to what the guys at http://manager-tools.com/ have to say...

good luck!