Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Possible Duplicate:
How do you motivate peers to become better developers?

How do you promote and how do you assure that in your new project best practices like unit testing, TDD, separation of concerns, SOLID principles and others are applied and used?

I’m trying to get there by setting a high target for the unit testing code coverage. I am thinking that to be able to properly test your code you are forced to do a better code design. However, this is going not going too well. After a few months we have projects with low code coverage and bad, ugly code.

I have the impression that the benefits of best practices mentioned above are not well understood and embraced by the team.

Your ideas on how to go to higher quality?

share|improve this question
Is this a greenfield or brownfield project? Improving the current practices on existing projects is known to be harder in general. – rwong Jul 26 '11 at 19:52
1  
Question 2. Is the development velocity too high, such that nobody is able to catch up with other's code, writing unit tests, and fixing bugs? (I assume you already have a defect tracking system and also put useful comments in source control commits.) – rwong Jul 26 '11 at 19:55
4  
What is your role there? Relative to others? Have you been there long enough to understand the priorities? If so, then I would recommend showing lots of positive examples, and carefully generating buzz such as those ideas become their own. – Job Jul 26 '11 at 20:38
@rwong: It is greenfield project, so I would expect to be easier to mor of the good practices on a clean start. I don't understand your 2nd question. The presure is high, but I expect that one by appling these, it results a higher quality which leads to higher eficiency – komisacroS Jul 28 '11 at 17:45
@Job: My role is of Team Leader & Tech Lead. Thanks for the advice, I will try to do it more often – komisacroS Jul 28 '11 at 17:46
show 1 more comment

marked as duplicate by Jim G., JB King, Walter, Mark Trapp Jul 28 '11 at 18:01

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4 Answers

Sounds like you have two issues: poor test coverage and poor coding conventions. Solving one does not solve the other. I'd recommend you approach each issue separately.

People are natural skeptics and may need to be convinced that these are areas that they need to improve. Identify their objections. Once you know why they object (e.g., lack of time, cost of maintenance, etc...), you can tailor your response to ease their concerns.

If there are no objections, you may need to explain the benefits as they relate to all the stakeholders (not just the developers).

If all else fails, then lead by example.

share|improve this answer
...or with a big bat. – Robert Harvey Jul 26 '11 at 19:40
1  
You should always lead by example. Code according to the categorical imperative. – Malachi Jul 26 '11 at 21:53

Have you considered code review. And include reviewing the test code as part of it. Code does not get pushed to prod until the code reviewer is happy.

share|improve this answer

The most effective way of getting people to adopt best practices is to make it easier to use them than not. A prime example was in one company who implemented a series of Word Perfect macros to aid the production of (non-programming) documentation. There was no compulsion to use these macros, but using them did make such documentation easier than straightforward formatting and typing. They were very widely adopted and improved the standards massively and quickly. Given that you are describing poor test coverage, and poor coding conventions, it might be appropriate to set up minimal code testing skeletons, with always fail tests in the skeleton by generation from the requirements, or from the code itself. Equally for the coding conventions, a "pretty printer" formatting routine called when code is compiled; or warnings from a cross reference listing, again as part of the routine for generating code might help.

I would emphasise that I do am not suggesting anything extensive, comprehensive or complicated - a very simple utility introduced will have have some effect, and multiple small utilities will be synergistic - the whole will be greater than the sum of the parts.

share|improve this answer

Personal interest is a key factor in making almost everybody get active. This is something I had experienced and it's so effective. It's not a theory, but maybe a managerial approach to involve the team in the benefit (or even lose) of the project. If you know that by selling the product, 1% of the total revenue would be yours (a team of 10 will make 10%), then you're more likely to work better and with higher quality, since you now have something to gain. This interest doesn't necessarily should be monetary. For example, an employee may work better, just because he expects to be presented as the best employee of the year at the yearly first of a corporation.

In other words, IMHO and as a suggestion, I think developers should get a feeling that they don't just work and are paid their salaries. Rather they should think that they will gain something subjectively valuable. :)

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.