Thursday, October 13, 2011

Following Convention

I was discussing a problem with an engineer I work with recently, and we basically came down to two ways we could solve the problem. They were basically equal; each had benefits and drawbacks, but neither was obviously a better choice.

There is, however, one big difference: one of the ideas followed standard conventions. The other violated them.

Let's talk about conventions for a second. Conventions are the well-worn paths in software. They're the habits that engineers pick up. Creating a branch per major feature and merging into master (thus keeping master pretty stable) is a convention of a lot of developers using Git. Giving a gag (read: really ugly) desk decoration to the developer who most recently broke the build is a convention followed by many engineering teams.

Conventions are a feedback loop. Tools help create conventions, and then conventions dictate what the tools do and how they work. Over time this makes it a lot easier to follow conventions. The tools support it better (fewer workarounds needed!). New developers joining the team can get up to speed more quickly.

So if our choices are equal in every other way, then choose the one that follows convention.

"It's easier" really is a good reason.

2 comments:

  1. So the question on my mind is: Was your solution the one that followed conventions or not? :-)

    (for some reason I can't post from my account)

    -Simon (appmbt.blogspot.com)

    ReplyDelete
  2. Simon - I try not to take sides! But yes, it was. The other guy simply hadn't worked with the technology in question before, so he was applying a convention from a different tech.

    ReplyDelete