Consistency is Key

It’s hard to be consistent, but so important. Being consistent means that others can rely on you to do what you say you are going to do. It is also an important facet of software development. Consistency means that understanding one part of the code enables you to understand the rest of it. Onboarding new engineers is much easier. Debugging issues is easier, even when you aren’t as familiar with that section of the codebase. Because it follows the same, consistent patterns that you know, you can follow it easily. This is why global brands (McDonald’s, Walmart, etc.) have become global. They are consistent in their experiences. You know exactly what you are going to get, regardless of what city, state, or country you are in (admittedly there might be some minor nuances in these brands in different countries, but it nicely illustrates my point).

There will always be times to break up the consistency and challenge the status quo. Introducing new patterns means you get to think about problems in a different way, but new patterns come at a cost to speed, reliability, and maintenance. Now you have to maintain two patterns, or even more. Which all of that can absolutely be worth it, particularly if the new pattern proves to be more efficient, but that does create tech debt. It also increases the cognitive load on your fellow engineers to remember how the two different patterns work. Get to a point where everyone is trying to remember fifteen disparate patterns across a variety of services and languages, and you start to have a very slow development process (unless you have a ton of engineers to spread the load to).

Startup development is usually inconsistent. You are moving so fast and building so many new features, it is hard to maintain consistent patterns. Worse yet, you don’t even know if a particular feature will be useful, so you build it with a bad pattern that you can quickly deliver. It creates tech debt, but if you end up deleting the feature, then you were better off with the way you did it. However, if that becomes the feature that works, well…keep reading. The company grows faster than the ability (or desire) to crush the tech debt, and this is where medium to large companies usually suffer. They end up spending large amounts of effort consolidating all of the inconsistencies created during their “hyper growth” phase. All while needing to maintain multiple versions of the same features because they have to continue supporting their customers.

I don’t have a silver bullet for being consistent or even avoiding inconsistencies. If I did, this post would have come out a week sooner. The reality is that it can be a part of the learning process (you think a pattern/feature will work, but it’s clunky, so you find a new one that is better), and there are also external factors that may end up making any consistency you had break down or worthless (because you sacrificed speed, thereby missing deadlines and losing deals or customers). The point is trying to be consistent as much as possible, and having very good reasons for when being inconsistent is unavoidable (or desired). Too many “one-off” inconsistencies, and some might start to think that is the default. The only thing that ends up being consistent is the inconsistency.