6

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?

2
  • It is highly dependent on the type of project, it's size, and how long you expect to stick around ;) ! Jul 13, 2009 at 10:23
  • @Mitch Wheat. Couldn't have put it better myself
    – zebrabox
    Jul 13, 2009 at 13:37

6 Answers 6

11

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 (git). 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.

4

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.

2

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.

2

Generally, I agree with the majority of the points already made. But I would like to respond to a few things that I don't entirely agree with. Along the way, I think that I'll weave together an interesting answer to your question.

From Dave Markle's answer:

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

Best practices are good ideas that work on most projects and most teams most of the time. Generally, they cover ideas that you would probably want to enact on a project, but there are also times when they are inappropriate.

An example of a best practice is "always use source control". The thing that you need to focus on, at least in this example, is not the use of source control, but the benefits of using source control, but also the costs (in terms of time, money, resources) that will be incurred, and then ask yourself if it makes sense to follow the practice or not given the project.

A few questions that you should be asking yourself about every best practice are things like:

  • Are we doing anything similar to this practice or that contradicts this practice?
  • What benefits does this provide?
  • What downsides are there to this practice?
  • Do we have the resources (people, hardware, time, money) needed to implement this practice?

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).

The biggest impact of introducing practices (or processes) into a project late is on thrashing. Steve McConnell has an interesting article on The Power of Process. Introducing process late on a project has the effect of decreasing the amount of time spent in productive work.

Many best practices can be implemented by freely available tools. However, just because the tool is free does not mean that the process is free. If your team isn't familiar with the tools (or, worse, the practices itself independent of tools), then you need to spend time and money to train them so that they can be effective.

You need to consider the "big picture", from people to processes to business to technical perspectives when changing how a project functions, especially in the middle.

From teabot's answer:

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.

I agree with this 100%. It's not about conforming to best practices, but it's about delivering high-quality working software to your customer on time and on budget (or, if you want to be a little more pessimistic, which reducing time and money overruns). It's not about creating a checklist of practices and following them to the letter on every project.

From soru's answer:

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

I partially agree with this. I feel that project retrospectives (or, for longer projects, periodic project health status discussions) are very important. The idea is to let everyone involved in every aspect of a project have a say in the good, the bad, and the ugly. It's also important to not focus on the bad, but the good too. I think that a three tiered discussion is best:

  • What is going well? Why is this working? Can we apply these to other projects?
  • What is going OK? Is this sufficient? Is there anything getting worse, that might put the project at risk? Can we improve anything during this project or for future projects?
  • What is going poorly? What impact are these having on the projects.

Capturing these and sharing them across the organization to other project teams should allow project managers, program managers, and other leadership to work toward process improvement and higher quality software.

1

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.

1

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.

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