Developer Guidelines - Department Philosophy Document

Question

I am tasked with creating a document for current and (most importantly) new developers that is a general guidelines for the department. This is not a document on what the server name is for Test, but probably more of a company philosophy document.

Some of the items I currently have:

1. Coding Standards (naming, the basics)
2. Tiers - how to use each tier (like the preferred method for database access)
3. Source Control - what we use and how we use it
4. Unit Testing
5. Namespaces
6. Promoting Code

What am I missing?

Answer 1

A mission statement. The one I've used before is:

"We are not here to write code, we are here to make money for the company."

This is useful if you have a team of people who write reams of low-quality (or high-quality, come to that) code.

Answer 2

• Perhaps associated with Source Control, keeping track of the licences for the libraries you may be using and keeping track of which code is yours (which you would be able to re-license later if you own the copyright).

• Version control and repositories.

• Associated with Coding standards, more than the name, the code formatting guidelines (easier to track changes with version control, otherwise things like change of spaces get in the way).

• Usage of a bug/issue tracking system, possibly with a workflow that's relatively simple (new -> assigned -> testing -> fixed, or something like that).

Answer 3

Documentation standards for source code. Remind them that one day, they may be doing maintenance on someone else's code, and remind them of the joys of maintaining well-documented APIs and logic.

Also, workstation setup guides. The last team I was one had documents explaining how to set up the workstation development environment for each application they maintained. It usually covered how to set up the projects in the IDE, how to connect to the servers/MQs/Database, and any other application-specific, non-intuitive quirks (and each app had its own peculiarities). For some applications, the set up was non-trivial (especially for newbies), and the process was its own document (apart from the others already mentioned).

Answer 4

Do you have any limitations? For example, "The company prohibits the use of Open Source software and/or 3rd party components".

Answer 5

Acceptable 3rd Party Licenses. We've had new hires work on a feature, then find out later on that they've included a GPL-licensed toolkit as part of it without realizing that was going to get them into hot water with our legal department.

Answer 6

Great list thus far.

In the spirit of "We are not here to write code, we are here to make money for the company." I recommend a guidelines for time tracking, estimation, and core hours.

Also provide a brief outline of the various roles in your group and others, their responsibilities and the various communication points.

Do you perform code reviews, retrospectives or follow any management methodologies like waterfall, scrum, etc? You might wish to provide a briefing on how you facilitate these activities.

There's also the new developer orientation stuff like how to connect to the printer, what's an appropriate email signature, how to request vacation time, etc, but I don't think your document necessarily needs to speak to these points. But maybe so...