Disclaimer: You and your team may not suffer from the issues described here. If not, hats off to you! The following recommendations are just that, recommendations. They are techniques I’ve used and they worked. Use them as I describe or as a template to for you own solutions. It isn’t about being right or wrong, but being consistent. If you have a well functioning team, I’d love to hear about how you do it so please write me.

This is the first post in a series of unknown length. Even though I do have a structured document that I deliver to my teams, I don’t plan on following any specific path with these posts. The topics will most likely jump from post to post as I see fit.

In this post I want to talk about consistency. Every company I’ve been to has had this same exact problem. Development teams are fragmented (e.g. skill level, understanding of concepts/technologies).  The two biggest issues I see with dev teams have are with vocabulary and tooling. Everyone has their own definition of what a ‘Model’ is and each one has their own favorite ORM.


This might seem silly. It might sound outright stupid but it’s a common problem and it’s also a productivity killer and cause of code related problems. Even I have been a victim of this. I was discussing a problem and potential solution with a team member. We were going in a loop and getting no where except frustrated. I was about to just give up and walk away when I realized something. He was talking about the same thing I was, except he was using a different term. I asked him to define his term and the definition he gave me was the same definition for the term I was using. Had we both used the same term with the same meaning behind it, we would have come to an agreement and saved 30 minutes of frustration. The argument may as well have been,

“I agree!”
“No, I agree!”
“Nuh uh, I agree!”

Another issue with vocabulary is management!!! They love to use words they think they understand but really don’t. This leads to confusion all around, with us and them. It’s a lose-lose situation.

How to standardize

Create a list of terms and their definitions. Pass it around to the team and have them review it, discuss it and make changes/additions based on feedback. The key here is not for technical accuracy, only to bring everyone up to the same understanding so that there is no longer a language barrier. Once everyone agrees on which terms mean what, stick to them!

You will need two (or more) lists:

1. Generic development terms. For example, the list might include technology stack specific terms like Model, View Model, Entity, etc. Be sure to define acronyms as well, “DTO, MVC, MVP”. Make the judgement based on your team, but don’t assume that just because you’re all seniors that everyone understands what a DTO is.

One big problem I deal with when it comes to management is that they don’t use the correct terms for the deployment process. They consider QA the same as Dev, and UAT the same as Staging. It causes so much confusion all around for all teams.

2. Project specific terms. For example, if you’re building an invoicing system, you will want to define terms like Quote, Order, Purchase Order and so forth. Building this list of much like building a Domain Specific Language. It’s especially important when there are industry specific terms that might not be known to everyone.

Recently I was talking to my team about a project. We were talking about a Coupon. The problem was a coupon can be digital and/or paper based. But no one was in agreement on if a digital coupon and a paper coupon should be treated as a single coupon with different states or if they should be treated as different types. Some treated as a state and others as a distinct type and the end result was a nightmare. Workflows were not compatible, nor was persistence. Had “Coupon” been defined before hand, we could have avoided arguments and code rewrites.

Be sure you define not only what a term CAN be but also what a term CAN NOT be.

Standardizing common and uncommon terms will improve communication and can be shared with management and stake holders alike. It also makes developer on-boarding easier.


No matter what problem you’re trying to solve, there will be no lack of tooling. Developer A loves Entity Framework while Developer B came from a Java background and prefers nHibernate. Who is right and who is wrong? Neither! All tools have their pros and cons and I’ve seen projects fall on their face because the original developer wanted to use tool X and he was the only one who knew how to use it so the next developer comes in and says, “We have to rewrite! He used tool X and he was an idiot!”. Projects are bound to be late or fail in this scenario.

How many times have you gotten into an argument with a developer about which tool to use? It’s ridiculous! It’s one of the worst arguments you can have. It’s just a pissing match.

How to standardize

Define the type of projects that your company will work on (e.g. web, mobile, desktop, reporting, etc). Then for each problem area, create a category (e.g. Web front end, web back end, data access, caching), then list the tools that will be used to solve each problem area. Sometimes you’ll end up with two or more tools that fit the need and that’s fine. Be sure to specify which tool to use when.

Pass the list around, get team consensus and work out any disagreements. Of course, someone will have to be the final word to prevent the infinite loop of X vs Y. Once the list is completed, enforce it!

Getting everyone on board with the tooling will reduce or eliminate the pointless arguments and will again help developer on-boarding. It also provides additional benefits to management because they can use it as part of the requirements when hiring new developers. My current company like to know what developers are using and the licensing involved along with costs.


The goal here is to start standardizing areas where developers like to squabble among each other to no end. Vocabulary and tooling are just the start. Standardization of processes (e.g., source control, deployment, documentation) would be the next step in getting consistency among the team(s).