Development notes: What a healthy development environment looks like

In my opinion, the best set up would include:

Software

Jira for issue tracking
A wiki for information sharing
Git for version control
Continuous integration and continuous deployment (e.g. with Jenkins)
Use an existing package provider like Redhat, don't compile publicly available software yourself

Environment

Full commit history available with details of developer name and change ticket ID
Full ticket history available to read, with no historical tickets in the "old" system and unreadable
/etc/init.d scripts ('service') for starting, stopping and restarting software
VMs for development
Identical production, development and test environments
Continuous Integration: Every check-in to any development branch is run through the test suite, and any failures are emailed to the author
Immutable infrastructure: Servers are not changed. All changes begin with pushing to a repo, and a new server is then built and deployed to a subset of users, tested, then to all users.
One-touch deployment, identical in both production and development environments

Continuous deployment: Every commit to trunk that passes the test suite is deployed

Refactoring code as required, restricted only by the need to pass the test suite
All major software components described on wiki with details of source code, restarting, troubleshooting, owner, etc.

Tests

Easy to run the entire test suite for any branch
Test suite should complete quickly
A test suite that is comprehensive and well understood by all
Test coverage stats are visible to everyone
Tests for hallmarks of quality like 'use strict' and embedded documentation (even if a blacklist of legacy code is required)

Code

Clear model-view-controller separation
All code contained within re-usable modules (scripts are thin wrappers around classes)
No "utility classes" (inherit/use roles if common methods are needed)
No "god classes" (split up methods into meaningul sublclasses or roles)
All logic contained within meaningful "noun" classes designed for problem domain
Meaningful variable names in domain language and no unnecessary abbreviations
Plentiful comments, written in the language of the problem domain
All classes/modules to have embedded documentation

People

For every piece of work, three people should discuss it together for a few minutes after a technical design has been proposed, and before any development work is started - a representative of the business, a QA tester and a developer.

They should ask questions like "Are the requirements accurate and high quality?", "Does the proposed solution fulfill the requirements?", "Is the proposed solution high quality?", "Can the proposed solution be easily tested?", etc.

The product manager as well as the people coming up with requirements must be readily available to answer questions.
To facilitate communication. teams should *not* be split across timezones

Development notes