Pets vs Livestock: Making the Move from Unique Creatures to Commodities

Details

Published: 08 October 2015

An analogy that caught the industry interest recently is a comparison of IT delivery styles with how we treat pets versus cattle.*  In a nutshell:

• Pets are owned in small numbers, uniquely named, hand reared and lovingly cared for — they are, by all considerations, members of the family. They are unique, lovingly hand raised and cared for. When they get ill, you nurse them back to health.

• Cattle are owned in large numbers, tagged using a standard system, identical, managed in herds, and bought and sold as a commodity — they are, in effect, food. When one gets ill, you replace it with another one.

• Many traditional IT departments are pet owners. Servers and applications are designed from an enterprise perspective — services are tightly coupled, relying on scale-up systems and relational databases. They are lovingly and expensively cared for, with great attention and affection.

• Modern commodity server users are cattle ranchers. Applications are designed to require little maintenance, to handle failure and to scale out. Services are loosely coupled and stateless. If a server fails it is easier to replace than fix — there is no emotional attachment.  Moving from pet owners to cattle ranchers would allow us to be more nimble and focus our efforts more on writing application code that makes us different.

I was feeling pretty good about myself for proposing moving to commodity servers, until I realized I am guilty of the same thing.

In my CSS files, I often write a quick patch for a specific use, and name it with something that seems relevant at the time.  I sometimes ignore the larger applicability of the style, or flexibility within SCSS, or neglect to migrate these larger style patterns to common repositories.  These styles are pets, and lead to anarchy and redundant CSS.

Going forward, we are adopting the BEM standard for CSS naming. BEM stands for Block, Element, Modifier. It is a method used to construct CSS class-names so they are consistent, isolated, and expressive.  The naming convention follows this pattern:

.block {}

.block__element {}

.block--modifier {}

.block represents the higher level of an abstraction or component.

.block__element represents a descendent or dependent of .block that helps form .block as a whole.

.block--modifier represents a different state or version of .block.

This standard focuses us on global uses for styles and makes it easier to find a style than guessing what unique name was chosen at a given time.

A few good resources for learning more about BEM methods are:

• CSSWizardry

• CSS-tricks

• Smashing Magazine

 

*This analogy was developed by Bill Baker at Microsoft, and expanded on by presenters at CloudScaling and CERN

Knowing where you are going doesn’t always require you to know where you’ve been

Details

Published: 04 November 2014

I teach orienteering and GPS navigation to Boy Scouts, and hear a lot from older Scouters on both sides. Map and compass guys always tell me they would never trust themselves to a battery-powered device when they are in the wilderness, and GPS guys scoff at the sets of directions like “go 342 degrees for 120 feet” and can’t believe anyone still does that. On the one hand, if you use a map and compass, you have to have a better feel for the topology around you and understand each step (pardon the pun) of getting from point A to point B. If you use a GPS, it doesn’t matter where you start, you can get to point B as long as you trust the technology implicitly and it doesn’t fail.

I see parallels in the discussions I have at work sometimes. There are older coders (like myself) who grew up with computers we programmed from the ground up, going through DOS and Unix commands, working intimately with the file system, and understanding HTML from the foundational levels. That gives us a strong background on which to understand the performance model of the software and what could be wrong when things don’t work as expected. On the other hand, younger coders don’t care that you used to have a DOS layer with Windows on top and a browser above that. They have been digital natives their whole lives and can take for granted much of the early years of computing because they rely on tools and frameworks that shield them from the minutia. They have difficulty when the code doesn’t perform as expected, because they don’t really understand everything that it is supposed to do in the first place. Having said that, they also can keep pace with change better because they don’t have a ton of bad habits to break, and they don’t have the same blinders on about what is possible and what isn’t. Not knowing something is impossible is often the first step to making it possible.

I am grateful I grew up when I did and have an understanding of what came before, while being able to take advantage of tools that don’t require me to code everything by hand anymore. It’s a balance that everyone has and I’m sure years from now the young coders today will be complaining that the new coders of the day don’t understand the CSS and Javascript libraries they are using in the next generation of technology. To quote Battlestar Galactica – “All of this has happened before, and all of this will happen again.” So say we all.

So Bad, It's Good

Details

Published: 06 April 2013

There is a fine line between awful and so awful it’s great.  These are the guilty pleasures that we all enjoy when watching something that is so horribly written, acted or directed that you can’t help but laugh.  That’s what made Mystery Science Theater 3000 such a blast – you got to poke fun at the movie you were ostensibly watching along with Mike, Crow and Tom.  Here are a couple of my more obscure “So Bad It’s Good” confessions.  If I can get comments working, I’d love to hear your confessions as well. 

Kaboom cereal is bad.  Really bad.  In college, I don’t remember if someone bought this on a dare, or got the munchies and thought it might be worthwhile, but there was a box purchased boasting of 45% of your daily recommended allowance of 7 vitamins and minerals (for those of you keeping score, this is just below pop-tarts on the nutritional scale).  The moment the milk touched the multicolored psychotic clown shaped nuggets, they dissolved into a formless gray mash.  Totally uneatable.Kaboom became a meme around our residence halls.  That box, and more to follow it, became traveling trophies of a sort, as they were handed out as house-warming gifts, door prizes or other random gift occasions.  Following the logic that we were all brought up not to waste food, and that gifts were to be displayed when the gifter is around, these boxes were passed from hand to hand, because no one would ever finish a box and feel right about throwing it away.  My roommate, Troy, used to carry a spare box or two in the trunk of his Impala, just in case a gift giving opportunity arose.

Steve Oedekirk is a genius.  Not at writing, directing or acting, but in getting us to spend money on garbage like this.  Thumb Wars and Thumbtanic, a Thumb Double Feature, is a parody of the real movies, acted out by thumbs with eyes and mouths greenscreened on.  Really, really bad.  The whole premise is so insipid that it reminds you of the stories we told each other of children, with no plot or direction, making it up as we go along and just doing whatever it takes to get a laugh at the moment.  Again, this is a great gift idea, because no one will ever, EVER, buy this for themselves.  His other films include “Thumb Wars: The Phantom Cuticle”, “BatThumb”, “FrankenThumb”, “The GodThumb” and “The Blair Thumb”.One thing I didn’t realize until talking with my friend, Kevin the FilmGuru, this past week, is that Steve Oedekirk also wrote the screenplays for Bruce Almighty, Evan Almighty, Barnyard, Ace Ventura: When Nature Calls and Patch Adams.

My Designs: Process Mapping through Prototyping

Details

Published: 20 January 2009

My wife doesn't know what I do at work.  I tell her all the time, but her eyes glaze over sometime into the second paragraph like mine do when she discusses her work in the neonatal intensive care unit.  I find my work endlessly fascinating, but I'm in the minority.  What I do is develop user experience designs from which talented developers create world class web applications.

The job is part psychologist, part librarian and part artist.  I have to understand organizational objectives and personal motivations, catalog knowledge and design components, and weave them together into a interface that so closely supports the intended task that it becomes invisible to the user.

I learned my craft over the past two decades after being exposed to a variety of methodologies and techniques.  My current practice most closely resembles the Performance Centered Design methodology developed at Ariel Performance Centered Systems and documented by Barry Raybould.

Business Process Mapping - A clear understanding of the current and desired business process, including what the business needs out of the process and how the user is incented to perform the task, is needed to develop a system that satisfies everyone.  These flow charts are then broken down into information needs for each step to ensure the user can make the right choices.  I don't usually have to do the process maps myself, but I usually influence them and must understand them.

Scenario Development - A scenario describes a single instance of a use case in as much detail as necessary to tell a story.  The scenario provides a narrative that can objectively be assessed to ensure the prototype solves the problem.  A number of scenarios are developed to cover variety of tasks, user groups and work contexts.  Sometimes I share these with my team, but often it's just a structure for me to demonstrate the prototoype.

Prototyping - The processes are divided into screens to support the task and an interface flow is developed to show how the screens interact.  HTML prototypes of the screens are developed and linked to support the story developed in the scenario.  The evaluators can see how the task progresses from screen to screen with as much fidelity in the data and functionality as necessary to understand the intended design.

Evaluation - Users review and identify holes in functionality, information or the process.

Refinement and documentation - After iterating through the prototype, the design will solidify and coalesce into an accepted design.  That design is documented with an annotated powerpoint of the prototype and user interface specification describing every control, behavior and data element present in the prototype.

Maintenance - inevitably, the scenarios don't cover anything, and sometimes technical limitations require compromises in the design.  As a designer, I stay involved through testing and deployment to ensure the system works in the real world.