Current Thinking

The story behind my Twitter handle

People who aren’t big Southern Rock fans sometimes wonder what my Twitter handle @mryankeeslicker means. Here’s the story…

I grew up in the 1970’s listening to Lynyrd Skynyrd and idolizing their lead singer, the late great Ronnie Van Zant. He told the best stories about life on the road as a whiskey rock and roller in the Deep South and their own hometown of Jacksonville, Florida. Those songs and stories took me to places and situations I’d never know.

Being from north of the Mason Dixon line, and perhaps a bit more big city than their liking, I always thought if I ever got a chance to meet Ronnie and his band, they’d see me as a “Yankee Slicker” – a fancy talking carpet bagger, not to be trusted, just as he sang about in Workin’ For MCA. That Mr. Yankee Slicker purportedly was none other than the legendary Producer Al Kooper. Good company to keep I say.

So, here’s to ya Ronnie – one more bourbon for road from a Yankee Slicker.

ronnieandme

Current Thinking

Mac to the Future. Happy 30th!

happybdaymac

DSC_0047

Broke out my collection this weekend to have some fun with MacPaint again. It was love at first sight then, and still is today.

here’s what you see pictured:

Mac 512k (1985)
ImageWriter printer
Apple 800k External Floppy Drive
Apple 300 Baud Modem
Complete manuals, cassettes
Original System Disk, MacPaint, MacWrite
MacPaint/MacWrite box and disks
dozens of misc 400k and 800k floppies
“Test Drive a Mac” carrying case

(All in working order :-)

So happy this all stills works after 30 years.

Happy Birthday Mac!

Current Thinking

Everything you know about Scale & Complexity is wrong

scalecomplexity

 

Over the last three years, I’ve had a chance to dig into designing for the extreme scale and complexity of the modern datacenter.

It’s been a great education in how to communicate clearly when there are severe consequences to everyday decisions. Because the modern datacenter powers the very core of our digital existence, it needs to absorb failure and keep ticking every second of every day, or face the wrath of millions (and much worse). Running some of the biggest services on the planet does in fact require massive scale and complexity of infrastructure – there’s no simplifying this situation away. And it will continue to grow every year for the foreseeable future.

While exploring the best ways for people to understand, take action and communicate what’s key to them at the moment in the datacenter, some important (but non-obvious) insights become quite clear. Turns out many of the prevailing thoughts in this field are wrongheaded, and it appears we have been going about this all wrong for a long, long time.

 


quoteSCALE
is not about numbers. It’s about fear.”




Extreme scale, or any amount of scale for that matter, cannot be addressed by putting more things on the screen. That doesn’t fix anything. When designing for understanding, it’s always a challenging task to compare quantities or depict large numbers to elicit the right response or get the importance across. But, trying to scare people into recognizing how gigantic something is by using various visual techniques rather than focusing on relieving the person’s fear of being crushed by the shear number of things to be managed is not helpful. So much effort is spent adding zeros and making typography heavier that we miss the human part of all this – how does this relate to what I understand and know how to deal with? Can I put this into perspective?

ANTIDOTE? Use compact and meaningful visual representations that leverage well understood metrics, rather than adding zeros.

 


quoteCOMPLEXITY
cannot be simplified, only clarified or illuminated.”




Complexity is so often cast as evil or undesirable by the Simplification Police that we sometimes forget its quite real, necessary and even unavoidable in many situations and environments. You cannot hide the intricate workings or obtuse relationships in a system and expect someone to fully grasp the gravity of decisions made upon it. We are brainwashing ourselves into thinking that anything can and should be simplified, which is true of many interactions, depictions and scenarios – but not all.

In fact, we do the biggest disservice there is when we cloak and discard important aspects of non-trivial systems or situations. Who wants to be in the dark for the sake of being spoonfed? Conversely, this doesn’t mean we should or would show every aspect of every object, person and process. But, it does mean we all need to recognize that complexity is not a bad thing, it just is a part of our world and needs to be clarified for people to make better decisions.

ANTIDOTE? Relay the key aspects and attributes without dumbing down the content.

 


quoteCOMPLICATED RELATIONSHIPS
cannot be expressed as a spilled box of spaghetti.”




The overall approach to showing complex relationships has historically been to try to depict every element of a set in an effort to be correct. Good thought, but terrible consequences for understanding and usability for non-trivial numbers of objects. Far better to realize that rendering a diagram that looks like someone dumped a box of spaghetti on the floor isn’t going to help anyone.

This pursuit of correctness makes things so difficult to understand in practice, it lengthens time on task. Worse yet, making that visual spaghetti look “appealing” adversely affects things by distracting us from getting to clarity. We need to focus on significance of related elements without being overwhelmed by the connections themselves, which is so often the case.

ANTIDOTE? Reduce the visual noise by using techniques that summarize without misleading.

 

 
SUMMARY

 
From the above insights you can see we have alot to reconsider, including an re-examination of our approach to depicting and communicating Scale, Complexity and Relationships in the modern datacenter.

I’d bet some or all of the approaches we’ve gotten wrong or outgrown also apply to your area of expertise and work.

Lots more to say about this topic.
Stay tuned. Or better yet, let’s talk.

mpell_sig