Archive for the ‘consistency’ Tag

The Last Refuge of the Unimaginative Mind?

I am a creature of habit.  I like this because it keeps me efficient, which keeps me happy, which keeps my coworkers alive.

This is another situation in which I work the way I naturally live.

Consistency in Experience

When you use an app or a site, it usually only takes a few seconds or so to really get the hang of how to navigate and operate things.  If all of the navigation is on the side and suddenly a navigational element is along the bottom, doesn’t your brain kind of badgerget tangled for a minute?  Personally, it makes my face scrunch up like a little badger. 

Keeping navigational elements consistent is a real key in usability; your users will get used to how to work something fairly quickly if it’s designed well.  If you have even small inconsistencies that confuse them, they will remember that they had trouble with the product and you will get negative press and unhappy customers. 

Another key example of an easy way to be consistent in design/experience is to keep your Yes/No, OK/Cancel buttons in the same place.  Doing some acceptance testing the other day, we noticed that the Cancel button was on the right and the Accept button was on the left in one area of the app.  Everywhere else it was reversed.  This was caught pretty quickly because we kept hitting Cancel when we meant to hit Accept.  Your users will do this too; your app is so usable that they just fly through everything without paying too much attention and then….they hit a snag. 

And then they make that badger face. 

And so on and so forth. 

Keeping the minute details of your designs consistent will keep your users moving quickly through your product and minimize the amount of thought they put into their use of it, which equates to great design.

Consistency in Development

On our team, we have some things that are just standard.  Things like all grids should sort, all active checkboxes should be checked by default if a user is Adding New, case searches should be wildcarded, etc.  These are items that we already know to do, and therefore we don’t have to add a lot of noise to acceptance criteria with these little things.  Muddying up the spec will make other items of actual importance get missed, noise reduces signal, yadda yadda yadda.  These are items that we have just determined will be standard, and as we get new additions to the team we make sure that they get informed of them (even if it means forgetting and kicking a story back and then telling them).  As these conventions build up over time, we ensure that our stories always represent the essence of a feature and don’t have to waste energy or space on the scaffolding around them.

Consistency in Documentation

Just like with the Consistency in Experience section, users will get the hang of reading a manual/help file/on-screen info prompt/tooltip/etc.  I know that sounds kind of silly, but little things can really make a big difference in user experience.  If you go into extreme detail about editing a user account in one section of a manual and then only make a blurb about editing a user location in a later section, it might make a difference.  People’s eyes will search for what they want to find, and if they are used to looking for headers like How to Edit a User Account and your location editing “section” doesn’t have that? badger face like whoa.

Now for the real meat of this portion of our show: consistency in stories and tests.  Tests should be consistent in naming and consistent in organization.  People should be able to easily read through the muck to get the information they need.  Back in the day?  I could never have read tests.  Now that we’ve cleaned things up a bit I have some idea of what is going on and how things work/are organized.  I can tell what stuff is because of the items surrounding it, or by the way it is named.  It makes it much easier and faster for people to read if you are consistent in the way you structure your tests.

When I write stories, I like to lay them all out the same way.  The same things get bulleted, the bottom of the story says “Mockup attached” if that applies, things get formatted similarly.  For example, when something needs to be restricted, the first thing in the backlog item is some bolded text, before the story, that says Permissions: [Whateverthepermissionsare].  This is great because:

a) Developers will see that right away and know to build it in

b) It doesn’t muddy up the acceptance criteria and cause something else to potentially be missed

c) with this convention, if there is no explicit permission statement there, developers don’t have to guess if it needs it or not

(note: these things go for the “Mockup attached” thing too…they won’t look for an attachment if that’s not at the bottom of the story, etc)

Using ubiquitous language is extremely useful as well.  We had a doozy of a time on our most recent project trying to figure out how to separate lab accounts and client accounts in stories…eventually we came up with those terms (and a bah-zillion others), and now our developers never have to ask me what the hell I’m talking about.

Oh, and, of course, as a developer I want my stories to be consistent so that I can easily identify each element of them.  Heh.

Consistency in Code (written by Scott C. Reynolds because I don’t know enough about code but I do know that this section is important to this post)

Teams usually come up with conventions in coding, or coding standards, that define how the team will do things like organize code, name variables, and things like that. This is helpful in communicating intent and reaching collective code ownership. For instance, the team standard may be "all private members are named with a leading underscore". Then anyone in the team reading code that comes across a variable named _someVariable will know that it is a private instance member and not a local variable, and will know to be concerned with things like mutability. This cuts both ways, in that the benefit gained from following the convention is about equal to the damage caused when someone doesn’t follow the convention.

Some frameworks, such as Rails, are built on the principle of "convention over configuration". In trade for following certain conventions, you get increased productivity by leveraging things the framework can do for you automatically.

Conventions become a sort of "meta layer" of communication on a team when people are doing things the same way; whether it’s naming variables, sorting classes into certain folder structures, calling things the same thing (ubiquitous language is a convention, and bears mention somewhere I think), then it removes guesswork from the equation and focuses communication on problem solving rather than mechanical details.Some frameworks, such as Rails, are built on the principle of "convention over configuration". In trade for following certain conventions, you get increased productivity by leveraging things the framework can do for you automatically.Conventions become a sort of "meta layer" of communication on a team when people are doing things the same way; whether it’s naming variables, sorting classes into certain folder structures, calling things the same thing, then it removes guesswork from the equation and focuses communication on problem solving rather than mechanical details.

Consistency in…General

Oscar Wilde once said “Consistency is the last refuge of the unimaginative mind.”  I would partially disagree with this statement.  By being consistent with the overall structure and feel of things, you can exert your mental energy into things that really matter, rather than minutiae.  Consistency in these small things means you don’t have to think about them; they exist as quality without any extra effort and greatly enhance the usability of a product, the understandability of a story, the ease of modifying tests.

…but maybe he wasn’t talking about software, hmm?

Like the Back of My Hand: Doing What You Know…Everywhere, or, Life Imitates Software

A while ago I wanted to start up an Etsy shop.  I had no idea what to do, as I am quite crafty but equally unfocused.  People told me “just do what you know.”  So I started making Beatles shot glasses and pint glasses (in case you don’t know me, I am disturbingly into The Beatles.  Thanks to all of you who do know me for putting up with it).  They sold pretty well and I had a great time making them.  It was easy.

When I wanted to start blogging, I had no idea what to write about.  People told me “just write what you know.”  Had to think about that one for a while before the first few blogs came out.  But the next ones were easy; usability issues are everywhere and even jokes made me think about software process issues.  All I had to do was look around and observe things and the answers were in front of me, because I knew them.  It was easy.

The point I’m getting at here is that these things were easy once I realized all I had to do was what I knew, and what I do on a daily basis.

The real point I’m getting at here is that this is obvious.  Doing what you know is easy.  Doing what you do on a daily basis is easy.  What reason is there not to adapt your life processes to your software processes?  Things that are second nature to you should present few problems in being applied to your software (though your team may take some convincing).  Really, it’s just a good way to figure out what is wrong on your team (or in your life) and figure out how easy it is to fix it.  Here is a small quiz about life and software development:

Scenario 1: You and your special someone have a miscommunication.  Do you:

a) Let it fester until the resentment has built up so much between you that you’re doing that “get the jelly, twat” joke in the middle of Publix but it’s even less funny than when Dane Cook did it

b) Talk it out until you are on the same page so that there is no tension and so that you can better handle similar situations in the future

If you said A, yer doin it wrong.  In the sense of literal communication, you need to be sure to discuss issues to keep the pair relationship and team relationship healthy.  Having a lot of tension between team mates can create not only a very unpleasant environment (for everyone), but will produce shittier code and probably mess up your velocity/cycle time (just because you’re is not functioning well as a team).  Keep your relationships healthy with communication (see: some other blog I wrote).  In the sense of letting things fester, ignoring problems or not resolving them right away is a fast way to fail.  Your system will get buggier and worse the longer you go without fixing bugs as they come up.  Fix problems as problems occur to prevent this kind of crap from happening.  If you said B, congratulations!; that was the right answer.  When pairing, dating, or even just working as a team, I find that JIT retrospectives are the way to go.  To me this doesn’t necessarily mean sit down after each feature is developed and deeply discuss every good and bad thing that has happened, but it does mean that during a weekly demo (or whatever form of that you do) you should talk about how things are going.  Iteratively handling situations will help you to grow closer rather than apart, and you will learn (in either scenario) much faster how to handle the situation as it arises and improve upon it from there.  We used scrum for a while and the daily stand-ups kind of handled this, but we really didn’t need to do it daily; it just ended up being wasteful.  Handling issues just in time at our weekly demos has proven immensely helpful to us; I recommend giving it a shot.  The big retrospective at the end still has value, but you might not even need it if you’re handling things as they come.

Scenario 2: You and your sweetie are planning a vacation to a secret remote tropical location.  Do you:

a) Plan out every detail far in advance and set a very strict itinerary

b) Keep a list of the items you want to do and set general ideas about when to do them

Why does A fail?  Rain.  Exhaustion from climbing a mountain the prior day.  Being hung over from a dastardly amount of rumrunners.  Whatever.  There are too many outside variables that you won’t know if you plan too far in advance.  Option B allows for plenty of change, and a more relaxing time.  Sure, you may need to set some things in stone if they are only available at certain times/on certain days, but for the most part keeping it easy will afford you a better vacation.  Change is a constant, so it is really the only thing you can plan for and ensure that those plans will work out.  JIT planning of your activities will ensure that you are always doing what you want to do next rather than what has been decided as your next item; JIT planning of your stories and priorities will allow room for change and make sure that the next thing you’re working on is the next actual priority.  Now, here I am kind of a liar, because I sure do like to make a good itinerary if the occasion should arise.  But I’ve fallen prey to all of the above downfalls I listed for A (especially the hangover), and also I’ve had great opportunities come up while I was on vacation that bumped other things off the list.  And they were worth it.  So I’m going to try out approach B for the next super secret remote island getaway I plan because I know it will work.  Because it works on my team.  These things, they go both ways.  Get it?

I could probably go on with more scenarios but a) your eyes might glaze over b) I think this is a good start.  Think about things you do and the way you effectively handle situations in your everyday life.  How can you apply these to the way you work, your processes, your team environment in general?  Are you working in a way that is contrary to the way you naturally work?  If so, why?  Start paying attention to things like this and see if you can find ways to improve by doing more of the same, but in a different area of your life.  All you have to do is look around and observe things and the answers are in front of you, because you know them.