How to justify to your colleagues that they produce crappy code?

Question

I am finding somewhat difficult to carry on working in my current job.

The codebase has become a bit wild lately (but definitely not the worse I\'ve seen), and I\'m havi

Answer 1

For starters:

1. Enforce the use of static code analysis tools. Every language has a few well known tools.

2. Show some before and after refactored code examples, and explain why you think it's better. Try not to put any one person on the spot.

3. Code reviews by experienced developers.

4. keep in mind, some developers can't be helped no matter how much you try...

5. If someone critiques your code be polite and open minded, you might learn something.

6. Cyclomatic complexity / number of changesets/bugs. Complex code is more likely to break, cause more bugs which causes more changes, which cost more money!

Answer 2

99% of the time you never get to choose the people you work with. Not all relationships work out, be they work or otherwise.

It would be best if your project was broken up enough so that each developer can contribute to a spec of what the other needs, so programmers don't step on each other's toes.

Getting people to change their coding style is hard. It takes a cast iron technical lead committed to such things and will help when you bring it up. Management types can't do this, leadership needs to provide technical details.

Answer 3

You could quit and hope to find something better.

Or, you could stick it out and try improve the code that you can control, when you can control it. No matter how well intentioned the developers are, if there is more than one developer the code base will be "ugly" by a competent developers standards. Work with the other developers to improve their abilities and refactor code as you make enhancements.

Answer 4

1) Make the problem more visible and get management buy-in

Keep a very detailed diary of the time spent on various coding tasks over the period of about a month. At the end of the month analyse and summarise the contents for your boss, i.e. time wasted and hence money wasted, to illustrate that change of some form is necessary.

2) Think of a cost effective way of moving forward

For example; Rather than refactoring the entire code base, seperate interfaces from implementations, and enforce tighter standards, including unit tests, naming conventions, etc.. at an interface layer. Thus each programmer can have confidence in using code that they have not written. While this is sweeping the crap under the carpet to a certain extent, it is a good way of preparing for larger scale refactoring.

It is important from a management perspective that workflow is not interrupted, and positive results are visible, so plan accordingly.

3) Agree longer terms improvements with your co-workers

Sit down and agree reasonable coding standards for future code with the other programmers.