In terms of specifying the actual code/syntax style that all developers should use in a project, should the project manager do this?
Or would that be under the realm of a technical lead/lead developer?
Or would it vary from organization to organization?
Or all of the above?
I ask because I feel having uniform, readable, commented code is extremely important for a project's success because it makes debugging and maintenance so much easier - so this seems like it'd be under the PM realm.
I'd say it's the teams responsibility, probably under the guidance of a tech lead, to agree on syntax style. That said, if a PM believes that it's just chaotic, they'd be within their right to raise it with the team as a potential issue.
Try not to introduce guidelines or styling that can't be automatically enforced.
Project manager should have nothing to do with this, even if they posses required technical knowledge.
Regarding comments. This will vary from organisation to organisation. Our culture is that we don't comment the code. Code must be clean and if it needs comments, then we probably need to re-factor. We are a team of over 20 developers working on a large enterprise system.
The following people should be involved in defining code guidelines:
Everything under a project is under the PM realm. However, on reasonably large, complex projects, the PM simply does not know it all. And making a decision like this, and many others, explicitly his/hers implies an authoritarian approach. It is, in fact, explicitly his/hers simply because the PM is the accountable role for the success of the project. But the PM needs to exploit the intelligence of the team to arrive at decisions such as these, even if the team result is counter-intuitive to the PM, no matter how uncomfortable that might be.
I think for something like this the PM's best approach is to facilitate the decision with the team, setting up the method of how to decide, working through conflicts and sticking points, removing whatever other barriers to a decision there might be, and pulling the trump card of overruling the team only as a last resort.
Rather than having the PM define the style, I would suggest that agreed corporate standards don't exist, a suitably qualified technical lead should be given a task to define the coding standards, quality expectations, etc. for the code. That way, the responsibility remains with the PM, but the technical decisions lie where they should: with the development / technical delivery specialists.
Similarly, the PM should not be the one to check that the standards are being applied. That is the role of project assurance. The exception to this may be where the PM is also supervising the development, but in such a situation it is arguable that the PM is fulfilling two or more roles, and the quality assurance is being done as part of one of the other roles.
While indeed everything on a project can be seen as the domain of the Project Manager, I like the "captain of the ship" analogy. For a small boat, the captain may repair the engine, be responsible for packing and handing out sandwiches, etc. On a larger boat, others specialize in these areas and the captain makes sure all the people function together.
For the specific case of code standards and style, why can't you (as PM) simply state that you expect the team to have a set of standards? You don't need to review them directly or approve them. Stating what is expected, explaining why it is expected and empowering your team to deliver works really well in these situations.
If you are the company experts in coding standards, you might need to adjust your style a bit as PM. Don't dictate the standards, but in communicating with the team ask questions that help them learn. (e.g. "How did you factor in transitioning the code to the maintenance team after release?") then if they have questions you can offer general suggestions, not solutions. Let them discover the answers for themselves and learn by doing. It might be painful in the short term, but it builds great teams that continue to learn and improve.
Every IDE has a key combination that applies a code style to the current file. In most cases, this will be the coding standard for the particular programming language. There are also tools that suggest the right (according to standards) naming and casing of code. I have seen that with ReSharper e.g.
So, I would just encourage all developers to use this shortcuts and follow these suggestions.
Those features can be adjusted to the company's standard also. Then make sure, that all developers are using the same config file of the company's standard.
Standards are easy. They are very well documented by the standardizing bodies. The W3C has very clear definitions of what semantically valid HTML markup looks like. Similarly, Oracle has very clear naming standards for classes, interfaces, and methods.
In fact, every Software Engineering student should at one time be introduced to coding standards, if not throughout their entire University career.
No matter what field we are in, the main goal of our education is to provide us all a foundation for communicating with other experts in our field. Coding standards are just one common way to ensure that a developer from a school in Maryland can step in and begin working on a very large, enterprise application developed by a developer in the UK, Oregon, California, or India.
In Business Administration, many of the terminology is used from region to region, such as "empowerment" or :MacGregor's Theory X and Theory Y" style management theories.
Standards help make sure people are on the same page and have common ground. They also go far beyond communication into the realm of good application design.
In terms of Google App Engine development, Google Engineers build sample projects that describe what they -- the technical experts on their platform -- believe is the best approach to building a scalable, extensible application... on their platform.
For Spring, the Spring developers post very detailed information in their documentation as well as in their blogs on how to approach situations, such as marshalling and unmarshalling objects from Java to XML/JSON and vice versa.
I know the other development platforms have similar standards.
When I want to know how to integrate with something a developer in our company built, I consult that developer, my colleague. When I want to know how to properly store an Entity object in the Google App Engine JDO datastore, I consult the Google Engineers who designed and built Google App Engine. If I want to know how to properly deserialize an object back to Java, and I'm using Spring, I consult the Spring development community.
In short, the decisions regarding standards must fall on the technical experts, whether that be the PM, a developer of an external JavaScript library, such as John Resig of JQuery, or a developer who built a module within our company. Anyone not following these professional standards has some serious explaining to do. I won't say they're wrong, but they definitely should come prepared to explain why they are ignoring the wisdom of the experts and taking an alternative approach. Best practices and coding standards shouldn't be dictated, but there are very real reasons why they exist. Ignoring them should not be taken lightly, and ignoring the need for them should be highly scrutinized.
It would have to be a very technical PM to force the specifics of a standard. This seems to fall under the realm of telling someone too many details on how to do their job. If there's a technical lead, you should leave it to them, though it is fair to require some kind of standard.
Think of it this way... You're the head of an event planning committee. You want to be sure that the 5 star chef you hired will make the best dinner possible. It's ok for you to ask for a list of ingredients to be sure they are thinking of making the right amount of food, but you wouldn't suggest what those ingredients are.
PM should never ever set coding guidelines. Only development team is responsible for that and it will be demotivating for the team if PM set this guidelines from the top.
However, PM can insist on coding guidelines existence and demand them from development team.
