Digital Sanctum

I’ve decided to put together a post of bad development environment practices that I’ve witnessed in companies I’ve worked for. For each bad practice there’s usually an easy fix to although the hard part is getting buy in and enforcing the change required to implement the fixes.

1. A project-wide compilation is done only once per week. This results in a long delay of knowing if there are issues related to checked in code and pending builds. Everyone actively working on the project should have access to the resources/scripts necessary to build the entire project so that issues can be found quickly and before checking in problematic code to the repository.
2. Only update the source related to what you’re working on. This is a dangerous practice and may and will lead to new code that’s out of sync with the existing code.
3. The current source control tool doesn’t support atomic check ins and checkouts. Instead it relies on file locking which results in lost time due to file contention or manually merging files. This also leads to developers not updating or checking in code as often as they should (several times a day) which leads to more lost time when it comes to merging.
4. Code gets checked into source control which doesn’t compile and/or results in runtime errors. This results in slowing every other person down on the team that may have a dependency on the broken code or just needs to have a working copy to test with. If source is actively being worked on that doesn’t compile, then a separate branch should be created and merged with the HEAD branch later.
5. Everyone’s development environment is on the same box. There are several changes (including db outages) that tend to happen on the box that never seem to get communicated to the proper people. This results in a waste of time for every developer using the box while they try to determine what the issue is and how to fix it. Because there’s just one user and corresponding permissions, it’s very easy to overwrite someone else’s files or global scripts used by everyone. When a mistake is made there’s no audit trail again because everyone uses the same user login.
6. No one seems to use the same development settings related to which databases should be used. Instead it’s a hit or miss battle to find one that’s available. Everyone should be hitting the same databases or have their own database instance with the same schema and similar data as everyone else. If everyone uses the same database and there’s an outage then everyone should be notified and switch to the same backup database.
7. There don’t seem to be standards related to attributing a bug fix code check in with a specific issue identifier. This results in there being no audit of what files were changed or added related to a specific fix or requirement.
8. Release notes for development builds including which bug fixes should be included are not clearly communicated or not at all. This can and should be easily incorporated into build scripts.
9. The final build artifacts have several versions of the same libraries. An example of this is commons-logging.jar and struts.jar. Keep the build artifacts meticulous and be sure there’s just one version of a required library.
10. Work is assigned before dependencies are completed. This results in extra time to put workarounds in place in order to get to the work assigned without the dependencies in place.
11. The standard library for application logging doesn’t seem to work and is not documented or there is no standard for application logging. This is a serious problem that can lead to developers resorting to rolling their own logging or worse yet, using something like Java’s System.out statements that get left in the code.