Don’t Make Me Choose To Follow The Standards

Most systems that involve humans making decisions have a set of standards: guidelines, rules and/or policies that help people make good decisions. These standards are usually in place for good reason – to prevent bad things from happening or to encourage good things. Software development and the software that we use every day are no different. For example, we set standards in how we develop our software: what language, what frameworks, the architectures, the application partitioning, and much much more. We also set standards in how people use our software – the user interface and how users interact with the system. Standards are all around us every day, even if we don’t recognize them.


Don’t Make Me Choose To Follow The Standards

In the process of creating the standards and the system that is built around those standards, we often have a choice in how we implement the system and standards that is overlooked: whether or not the standards are the defaults. We can implement a system so that we must explicitly choose to follow the standards, or explicitly choose to deviate from the standards. The right choice – which isn’t alway obvious – is to set up the system so that the standards we want to follow are the defaults. We should not have to think about too much about implementing them. It should be easy and natural – the default way – to use the standards that are in place. Thus, when we need to deviate from the standards, it must be an explicit choice.


Helping Users Make Good Decisions

By making a system default to the standards and making deviation from the standards an explicit choice, we employ human psychology to help police the system and encourage users to make good decisions.

For example, Joey and I have been talking about security in our app lately. We have 2 major roles in our authorization system: managers and admins. At this point in time, a manager can work with patients in the system and an admin can create and edit managers. When we first started discussing this setup, we made the assumption that admins could do anything in the system. After all, they are admins… if they can create and edit the other types of users in the system, why not just let them have free reign to do whatever they want?

After some discussion, though, we realized that there are some potential issues with the way we wanted to set up admins. We don’t want admins to have free reign over the patients, directly. We need more accountability in our system than that, and we need to ensure that only the managers who are assigned to the patients can work with them. An admin may also be a manager, but we wanted to make that an explicit choice. In the end, we separated the role of manager and admin and require an explicit selection of both if a person is both. If you are only an admin, you cannot manage patients. If you are only a manager, you cannot create and edit other managers.

The net result of this decision is that it is now an explicit choice for an admin to create a manager (or assign themselves the role of manager) and work with patients. By having this be a decision that the admin must make, and not the default, we are encouraging admins to think about whether or not they need the rights to work with patients. Of course, it’s still simple for the admin to modify their own account or create a junk account with the rights to work with patients. At the very least, though, we’ll help keep the honest people honest.


Helping Developers Make Good Decisions

The same principle applies to the code that we are writing in our software systems, too. We can make decisions and implement parts of our system so that it must be an explicit choice to follow or deviate from the standards.

In the same app that Joey and I are working on, we had to make a decision concerning how we wanted to secure all of the pages in the system. At first, we set up a single controller (in Rails) to require authentication. When we got to the next controller that needed authentication we stopped and discussed our options. The basic options we came up with were to either duplicate the one line of code in every controller that turned on authentication requirement, or wrap that up in a help method or module and include that in every controller. Either way, the approach required us to remember that we needed to secure the pages via the controller. The second way would at least abstract away the specific authentication mechanism we were using, making it easy to change later.

Neither of us liked either of these options, though. Not only would it mean code that we had to remember to put in place in our controllers, but it also meant potential problems by forgetting to secure things. This lead to the realization that we would need to write a test for every controller, to ensure that we had the authentication requirement in place – more tedious repetition and things to remember. Ugh.

After some additional discussion, though, we realized that the app we are working on is going to have very few pages that are not secure. In fact, there’s only 2 pages in the system that are not secure right now: the home page and the sign in page. All of the other pages and all of the other controllers are secured. Therefore, the rule is that controllers must be secure, and the exception is that a few pages are not.

With this in mind, we decided to implement the authentication requirement in the base controller (ApplicationController) and provide a way to ignore that requirement in the base controller, when needed. This solved several of the problems that we were running into with the other options.

  1. It prevented us from having to remember to put in the authentication requirement on every controller
  2. It prevented us from having to remember to write a test to prove the authentication was there, on every controller
  3. It allowed us to create a very small number of tests around only the base controller, to prove that we required authentication in our system
  4. It made the need for a non-secure page an explicit choice, instead of making the need for a secure page (the standard we needed to follow) a choice

Now our system is nice and secure, and we don’t have to worry about whether or not we put authentication into any given controller. Of course, authorization still has to be added to the individual controllers, but we expected that. Authorization is much more fine-grained than authentication in our system and we are not yet sure if we can generalize it to the base controller (seems unlikely, off-hand).


About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Analysis and Design, Management, Pragmatism, Principles and Patterns, Security, Standardized Work, User Experience. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • jdn

    Confused about the title of the post and the meat of it.

    Why shouldn’t you allow the choice to follow standards or not?

  • @jdn,

    yeah – i struggled to title this one for a while… I was going to title it “Don’t make me choose to follow the standards. Make me choose to deviate from them” – but that was far too wordy.

    I couldn’t think of a better way to express what I was trying to say, so I just chopped it short hoping it would become obvious once the content was read.

    guess it didn’t quite pan out the way i hoped.

  • jdn

    Okay, that’s understandable.

    That aside, in all seriousness, what is the point you are trying to make? It seems like you have a good point to make, but I can’t figure out what it is.

    Admittedly I’m slow, but there seems to be a disconnect between the “Helping Users make good decisions” section and the “Helping Developers make good decisions” section.

    I’ve written more worse blog posts than you’ve had Sundays (I have no idea from whom, but I think I’ve stolen that from someone, I just think it sounds funny), but maybe you might think about reformulating your main point into another post. It just doesn’t seem to tie together.


  • it’s a rather abstract point, which is probably why i’m not doing a good job of making it clear. the connection between those two sections is the abstract principle. if i’m not making the principle clear, then those two sections don’t seem to be connected at all.

    … hmm… how to word it differently…

    i shouldn’t have to choose to follow the standards. i shouldn’t have to remember to follow the standards. i shouldn’t have to explicitly make a decision to implement or use the standards. i should only have to choose to deviate from them. the standards should be the default way that the system works. but the system should still allow me the freedom to deviate from the standards, when necessary.

    not sure if that helps, or if i’m just saying the same thing again.

    i think @thetamind summed it up pretty well via a comment on twitter: “Reminds me of convention over configuration in #rails. Smart by default. It’s simpler to only specify exceptions to the rule”

  • here’s a few more examples from conversation w/ @thetamind on twitter:

    @thetamind: “now how far do u go? Enforce passing test/code style on commit? Get flak for protecting user experience aka Apple app store?”

    me: “if xcode and the ios sdk made usability so easy that you had to jump through hoops to make a bad app, that would be a good thing”

    me: “enforcing test / code style on commit is actually the opposite of what i want” … “i want test / code style to be baked into the way we work, so that we don’t have to check it”

    maybe the additional examples how clarify the point?

    the way we work should conform to the standards we have, without extra effort. it should only take effort to deviate from the standards.

  • jdn

    Okay, that’s starting to get somewhere.

    When you put it in those terms, I start to think about how I (personally) think about standards depending on context.

    When working on a team of, say, 4 developers, the notion of standards means a lot different than when I’m working on a team that has, say, 50 developers.

    Having dealt with both recently, you really do get a different sense of the cost of deviating from a set standard.

  • Good post. I get what you are saying.
    Simple example I can think of…

    All my navigation classes should have a Go method.
    So I create a abstract base class that has an abstract Go method.
    Now the standard of having a Go method for all navigation classes is nicely and easily enforced, because if someone inherits from navigation they have to implement Go.

    Standard becomes default.

    It’s a very powerful concept. I try to use it all the time when designing a framework. So much better to capture convention explicitly by making it default, rather than relying on teaching and memory.

  • jdn


    Ah, yeah, that’s a good example.

    So, Derick, using his example, would deviation here be a case where you make an exception not to inherit from the abstract base class?

  • Joakim Brännström

    Regarding Authorization, wouldn’t a convention save your day here too? Eg. all controllers under. /admin require administrator privileges. All controllers under /manager require… You see where I’m going?

  • Joakim,

    In our case – no. Every page except /login must be secure. If you are working on a system where only certain pages must be secure, then yes, that would work.