Why you should be building software based on conventions

Conventions are ways of doings things that are tried and true. A set of rules we mutually agreed on. They cover the most common use case and are generally the preferred way of tackling a problem. Some of us dislike conventions. They are considered boring or leave too little room for creativity.

Regularly we come across problems that are yet to be completely understood. While working on the problem a more comprehensive picture starts to form. When the dust has settled we often spot similarities between the problem we just solved and problems we solved before. Patterns emerge.

Sharing conventions amongst a group of people is immensely beneficial. When coming across a well-defined problem one simply refers to the convention; problem solved.

At this point you might be thinking: "Our problems are never so clear-cut!" and I'd beg to differ. Some really are. How many companies have built RESTful APIs in the last year, but failed to implement a comprehensive standard? Or wrote a bunch of JavaScript spaghetti code instead of using a battle-tested framework?

Many of us feel that our use case is exceptional, or fail to understand the benefit of a readily available solution. Sometimes just to tickle our engineering fancy of creating something from scratch. The truth is that you just aren’t that special.

By settling on conventions you can achieve the following things:

• Reduce the on-boarding time of new team members

• Leverage the knowledge of highly skilled people outside of your own organization

• Increase productivity by focussing on problems specific to your domain, rather than auxiliary issues.

Building good software is already hard enough. Don't become a victim of "not invented here" syndrome. New conventions only really stick when they are truly superior to whatever is already out there.