At first glance, this looks completely reasonable especially if you consider that each corresponding environment declares a container-level variable whose value is one of the directory names (Development/Integration=dev, UAT/Test=test, etc.). Developers get to configure each environment and at deployment time the server simply knows how to behave based on the preset environment variable. Sounds OK, right?

NO! It isn’t OK. It is horrible and you should never do it. Packaging configuration in with code leaves the System Administrator powerless to administer the system. See the problem? No? Here are more reasons:

• Configuration changes require a redeployment of the application (possibly even repackaging)
• Developers may not (indeed, should not) be privy to certain config information (passwords, let’s say) for production environments
• Test environments of the same “level” can’t have differing configuration unless you jump through hoops like branching source code
• Turning a dev/test/stage box into a production one (or vice versa) with one small change is just scary
• A developer can change production and nobody will notice until the code gets to production!
• A developer can change production and nobody will notice until the code gets to production!
• A DEVELOPER CAN CHANGE PRODUCTION AND NOBODY WILL NOTICE UNTIL THE CODE GETS TO PRODUCTION!

Get it?

The way to manage configuration is to provide a nicely-commented prototype config file (that can’t/won’t be read) with your application and leave the runtime configuration in a file outside the deployed application path. There are many ways to make such files available to your program regardless of whether you’re using a container or not. You can:

• Add a conf directory to the runtime classpath
• Put the config files in a known directory such as common/classes on Tomcat
• Jar them up and name them according to environment, if you just absolutely must not let the admins touch them.

Any of these tactics work. As long as you aren’t marrying code and configuration, you can’t miss.

Sure we do the best we can with JIRA (a fantastic traditional bug tracker) and MS Project (a not-so-fantastic project management tool), but there doesn’t seem to be a good selection of tools to mimick an agile team.

I want creamy visual objects that represent features which can be moved between developers.  I want a view of each developer’s workload for the next week, month and year.  I want to know in 10sec what’s going out when, and which tasks are the limiting factor.

The closest thing I’ve found is VersionOne, and I haven’t had a chance to fully evaluate it yet.  If anyone has any clues, I’m all ears.