This blog post is all about: what can be (effectively) visualized, when visualizing works (brings benefits), what does it mean that visualization is "effective", why visualization makes a difference, why visualization is not just about sketching something that comes to your mind.
One of the defining moments in each professional Software Engineer's career is when (s)he realizes her/his limitations - that (s)he can do only about as much but not more. That it's not possible to up-scale her/himself anymore & out-scaling is the only option (if one is really determined to achieve MORE).
That is the exact moment when the communication is elevated to the rank of a biggest enabler ... and constraint. When it's not (anymore) enough to keep the details of the solution in your head - you need to share (& sync, & validate, ...) them with other people. Now the hard part begins.
There's one particular skill that is extremely useful at this point. I'd even say - absolutely necessary. It's one of the skills you don't get born with, but it all comes out of practice:
Visualizing. The. Work.
What does it really mean? If fact, multitude of things:
- visual decomposition of the problem ("slicing the elephant")
- visual overview of the solution (structural aspect)
- visual depiction of work to be done (planning & execution aspect)
- visualized interactions & dependencies (dynamic aspect)
- ... and many more
Wait. But why "visualizing"? Is the "visual" part of communication so crucial? Couldn't I just "describe" it to other people? Write an article? A specification? A formal document?
Nope. Apparently there's surprisingly much wisdom in the old adage:
A picture is worth a thousand words.
How come?
The secret of visualizing
Visualizing doesn't mean just scratching something without rhyme or reason. It's using the more concise form of ubiquitous language, optimised for throughput that works if and only if:
- you follow common conventions (e.g. "a line with an arrowhead at one of the ends means a directional relationship")
- you propose intuitive new convention(s) that don't need much elaboration
- you use basic multi-dimensional classification - e.g. depict dimensions of a problem (e.g. attributes of data) with the following means of expression: 2 dimensions of standard table, list in a cell as a 3rd dimension, element size as 4th dimension, element color as 5th, etc.
It's like with a good joke - good visualization needs no explanation (or at worst such one you just need to skim through). In fact you don't need sophisticated techniques for that - quite the contrary: the easier (& more approachable) the notations, the better (& easier to understand).
Bad (& complex) visualization just obfuscates your thoughts even more.
"Working" (effective) visualization is beneficial because it:
- significantly reduces the cognitive load (makes things easier to comprehend)
- provides "structure" & "composition" for whatever it covers (aka the conceptual model) - now, when you're discussing something it's much more probable that all parties have a good (shared) understanding of what is it ;P
- is not linear (while written documents are - which is often a dramatic oversimplification of problem space) - which makes it much more flexible in representing non-trivial abstractions
- is far more expressive when it comes to fast scanning (skimming), jumping across sections (/dimensions, /sub-models, etc.) or any other kind of "navigation" - because it's my easier to distinguish common "reference points"
A common ground
To keep the long story short - visualization is the easiest & fastest way to sync the conceptual models (yours and other people ones). Because when facing a problem, different people can come up with very different (but equally proper & correct) solutions that may be very challenging to map between, refer across & (in the end) align.
That's where visual model shines. Because it forces parties to FRAME the concepts into some common terms/notations/conventions - which significantly reduces the complexity of aligning. And getting to some common ground.
Getting there
Visualizing information is a practical skill - it needs regular exercising, it can be worked out, it gets rusty if you stop using it at some point. It's not "mechanical" or "aesthetic" - in fact it depends rather on being able to distinguish abstractions & classifying them (based on common & independent things) than on appealing presentation.
Visualizing requires a lot of clarity in thinking - as the output has to be clear & self-descriptive not only to you, but also to other message recipients. Visualizing is never about perfection (because there's no single, "perfect" solution) - it's more about practical "agility": being able to evolve your depicted thoughts into something else quickly & smoothly (if conditions change, new facts get revealed).
And at last but not least - visualization is crucial regardless of your role, because it's a collaborative experience. The goal is NOT to create a graphical representation that fits only you, but to gather up and craft something together (everyone should participate & contribute) - a common vision all of you treats as your own.
