Best Practices or Project Standards

Question

As a software development contractor I've worked on many projects with differing standards and conventions. Quite often these conventions go against the software best practices we know and 'love'.

The question is, when you're working on an established project with specific ways of doing things that you know aren't the best ways, do you break the conventions of the project because you know its a better way of doing something, or do you stick to convention meaning that your work will blend into the existing code base? After all, you need to keep in mind someone else is going to stumble across your work one day and if its not consistent with the rest of the project they will have to take the time to work out what you've done differently.

So, project convention consistency or best practices?

Answer 1

I have a saying, and I don't know if anyone else has said it before me, but I like to think I invented it.

"Blindly following best practices is not a Best Practice."

Basically, it depends. If your client is not using Source Control, then yes, that's a big problem and IMO is a battle worth fighting especially since fixing the problem costs a client $0 (SVN). If someone's not using your naming convention, then I tend to suck it up and go with the client. There was this time though, when a client prefixed every column name in a table with the tablename. Columns literally looked like: Person_PersonID. Again, that, IMO, is a battle worth fighting.

OK, actually, it was worse than that. Instead of calling their budget line item table "LineItems", they actually called it "BudgetDepartmentProduct". Which of course, made the table's PK "BudgetDepartmentProduct_BudgetDepartmentProductID". You have to love that. Of course, nowadays with stuff like Linq to SQL, it's fairly easy to put some sugar coating over that pile of poo and not interact with those names as a programmer. But this project was instead hundreds of cut and pasted stored procedures. I fought against this and lost. This is why I bill by the hour.

So your answer ends up being "it depends". A really good consultant learns by experience what battles to fight, and in my experience, most clients appreciate the honesty if the argument is made in a way that doesn't damage team ego or morale. That requires judgement and building up trust a lot of times first.

Answer 2

If I get to work in a project that are following standards that I do not agree with I do two things:

• I follow the standard in use
• I argue for a better way of working

Often there are (more or less well-founded) reasons why the work is done in the way it is. If so, it may very well make sense, even though I might not completely agree with it. If there are no well-founded reasons for the given structure, I often find that there is room to help introduce better ways of working.

Answer 3

I guess it depends on whether convention and consistency is working. If the current practices are really against best practices then surely they are having a perceptible negative impact? If they are not - then what is the motivation for change?

It might be the case that some best practices will only visibly benefit in the longer-term. This makes them a harder sell if convention and consistency is delivering what is required in the present.

Personally I have a set of practices that I like to work to and would hope to employ in any team in which I find myself. However, I do try hard to recognize the value in conforming to existing practices if they yield the results expected and required.

A classic example is code formatting style: The value is not in the style itself (so long as it is reasonably sane) - the value is in the team adopting a standard style.

Answer 4

Are the project standards:

• Written down?
• Followed in practise by people on the team?
• At least arguably sensible?

If any two of the above apply, follow them. If they are being followed and enforced, but are objectively stupid, try to get them changed. Otherwise, just quietly do the right thing.

Answer 5

Make sure what you want to do different is actually better (overall) and not just different and ENSURE you know why things were done a certain way (don't just rely on reading the code, ask someone who was part of the decision process). If it turns out you do have a better way, use it, Colon Powell said one time to always question the experts - it makes everyone better. Just ensure you document the approach, communicate to the rest of the team (get buy in) and plan on refactoring the existing code.