"Best practices"

Some lessons I've learned:

• Every company believes that other companies use a much more structured approach to development than it does.
• Generally, you have a trade-off. If you do go for the structured approach to development, with change tracking, QA, development/test/stage/release boxes, and separate organizations in charge of each step, then it's going to take two weeks to change a typo. On the other hand, if you let developers make changes on "production", it'll take two minutes to add an important new feature, but it'll break everything else.

In the end you have to come up with compromises that suit your particular situation although there are also approaches that help when deciding how your software is designed.

One of the best things you can do, in my experience, is to design the software in such a way that every developer can install it with ease on a computer under their own personal control. This is another reason I like the Java web approach - IDEs like Netbeans have much of the core technology stack built in, complete with Tomcat, the web server. Develop on your own machine, deploy a WAR file containing the application to a test server, and then when that's signed off deploy the same file to production. The only additional set-up a developer typically has to do is to add a database.