Skip to content

Steve Hill

Creeping Inconsistencies

team, code, javascript1 min read

Why is it done like this over here, but like that over there?

- Every programmer, ever

Inconsistency costs development teams time in a number of ways.

  1. prompting questions of needlessly-differing approaches
  2. spurring technical debt cards to be written
  3. creating meetings for technical debt prioritization
  4. requiring huddles for effort estimation solutions

For architectural debt, and overarching concerns, creating cards and prioritizing them are effective. My experience with smaller items such as enforcing a particular return style from JavaScript functions is the opposite. Consistency is in the best interest of everyone, and is best enforced by an aggressive developer simply doing it.

Returning Inconsistencies

While working in our front-end code, I noticed we had a 60/40 split in the way we returned from our JavaScript view models.

1var self = {};
2self.shippingModeOptions = ['Sea', 'Rail', 'Truck'];
3return self;
1// vs
3return {
4 shippingModeOptions: ['Sea', 'Rail', 'Truck']

My process for dealing with this type of inconsistency is two-fold.

First, determine the differing ways we're accomplishing the same thing I found the two above.

Next, decide which is better. I prefer the second style for a couple reasons.

  • Everything this function returns is together
  • It's succinct

Library Usage

We've been using the excellent KnockoutJS library since long before the 2.0 version, but we've also been quick to upgrade to new releases. Just like you'd expect for a major release, KnockoutJS 2.0 came with some API changes. We had an 80/20 split in the way we create dependentObservables.

1var title = ko.observable('Mr.');
2var firstName = ko.observable('Ellis');
3var lastName = ko.observable('Dewald');
1// ---
3var fullName = ko.dependentObservable(function(){
4 return [firstName(),lastName()].join(' ');
7// vs
9var formalName = ko.computed(function() {
10 return [title(),firstName(),lastName()].join(' ');

In KnockoutJS 2.0, ko.dependentObservable was renamed to the more terse ko.computed. This is problematic for a few reasons.

  1. You'd have to be reading the KnockoutJS computed documentation to find out what a dependentObservable is
  2. It's reasonable to expect that these two differently-named functions do different things, which again takes time in the form of questions, explanations, and googling.

The point is not to create an atmosphere where questions shouldn't be asked they're a critical part of the success and cohesion of any team. The point is to spare the team from spending time on low-value questions. Quashing the existence of two equivalent, but competing, styles is a great way to ease the transition of new folks and encourage time is being spent on those high-value questions and conversations.