One of the most pervasive enemies of software developers is friction in their technology choices. Few things can kill morale quite like the frustration of a framework being completely unintuitive or downright overly complicated. That said, how do you differentiate between something being unnecessarily complex, and just complex? After all, there are difficult and abstract concepts in this field that require knowledge and experience to grasp. A recent run-in with Geico made me ponder where the tipping point is between acceptable and unacceptable complexity.

I recently decided to reevaluate my budget to see where I could trim some fat in order to put more into savings (I’m not getting younger after all). Part of that included me looking around at competing car insurance companies (I’ve been with Geico for ~5 years) to see what kind of rates I could get. After getting some quotes, it turned out I could get the exact same coverage, with another company, but for $50 less a month. Not a huge savings, but it adds up when combined with other budget cuts.

I decided to call Geico to give them the chance to keep my business before jumping ship. I politely told them the savings I could get, and asked them to match it. Unfortunately they couldn’t discount my policy any more than $7 a month (still $43 a month more than a competitor). What really frustrated me though is that they insisted on continuously telling me about services that Geico offers that supposedly merit their higher rates, and that I should stick with them because of them. None of the services they rattled off were actually beneficial to me though, and therefore didn’t warrant the extra cost.

This mentality that superflous features can merit extra costs is absolutely ridiculous, and I refuse to be talked to like I’m an idiot. In the case of your personal budget, the highest order bit is money. You want to get exactly the service you need and pay as little for it as possible. As soon as a company forgets that and tries to trick you into thinking you need something else, they have failed you and society as a whole.

The same principal is very much true when it comes to technology, but in this case, the highest order bit is simplicity, not money*. Therefore, when selecting a technology to use, you should focus on finding something that gives you exactly the functionality you need, and is as simple to use as possible. Sadly, many framework developers/companies forget this and try to contrive value propositions based on unnecessary use cases and features that are supposed to make the overcomplexity merited somehow.

* There is a HUGE caveat to this statement that revolves around scenarios where money is the highest order bit, and it isn’t simplicity your searching for, it’s a consumer base. The two best examples of this are Facebook and the iPhone. Both have traditionally had horrible developer experiences (Facebook is vastly improved these days), but people put up with it because of the monetary opportunities. Ultimately, it’s usually always about money, but in non-consumer facing development, time is money, and therefore simplicity is what creates savings.

Another flaw that framework developers can make is assuming that people will be compelled by “soon to come” features. If simplicity is needed now, then only the alpha geeks will put up with friction when promised something better in the future. When a product determines what its core value prop/usage scenario is, it needs to do that very well, otherwise it’s existence is straddling irrelevance. If the scenario isn’t contrived, then someone else will come along and make it easier to solve in less time. 

I’m by no means saying that a project should stay in development until it is “perfect”, leading to a perpetual beta. At some point you have to make a release. But, a release should have an objective, and if it hasn’t reach that objective yet, then releasing it would be completely pointless and a waste of adopter’s time.

Geico also made this flaw, by telling me that in about a year, a speeding ticket would fall out of the grace period and I could be offered a “good driver’s discount”. As mentioned before, the priority here is monetary savings, not longterm loyalty to a company who can make me future promises. There’s nothing stopping me from switching company’s (and saving money) and coming back to Geico in a year when I’m elligible for the discount. This is another example of how they assume I must be an idiot.

There are so many times when I decide to evaluate a framework for use in a software project and I feel almost insulted by how ridiculously unintuitive it is. Either it’s too hard to use because it tries to solve every issue known to man, or it doesn’t seem to actually understand how to solve the problem it’s seeking to, therefore coming off as very immature. In either case, I have zero patience for it, and neither should any developer.

So, how can you tell if a framework isn’t suffering from the “Geico Effect”? Try asking yourself these two questions:

  1. Does the technology provide a simple to use solution for a real problem without being overcomplicated by superfluous features?
  2. Does the technology completely solve the problem at the time of use?

If you can comfortably answer yes to both questions, then the technology you’re using is most likely pretty solid, and is being developed by someone who actually gets their audience. If complexity exists with the product, then it is most likely a necessary evil, as few things in life are actually dead-simple. 

If you can’t answer yes to those questions, and you’re using a non-beta product, then you’re probably better off moving on, and saving yourself some precious time and sanity.