As I have progressed throughout my software career I have noticed a trend that proliferates through many aspects of my craft. Specifically, that is the importance of not knowing every detail. For instance, consider the power in producing a useful abstraction. The power is derived not from the details you share, but the details you don't have to share. Since the word "abstraction" has many definitions, I will offer mine for the sake of clarity.
Abstraction
The calculated, contextually subjective selection of relevant detail to reduce the complexity of some subject for facilitating simplification of thought and communication about that subject, or the product thereof.
That is a lot to take in, however I'm guessing this is not a new concept for most. What I find interesting is that the inherent value of any given abstraction changes depending upon its applicable purpose. For instance, Motor Trends™ magazine presents awards to car makers within a given category like "Compact Cars" or "Minivans". However, it's probably easier to teach your child how to sort their Hot Wheels™ by color or size instead of by Motor Trends category.
When I started to transition into a Software Architect role, I thought about this idea a lot. In fact, in one of my performance review self evaluations, I referred to the ability to know the unknowable as an "Architectural Spidey Sense", a quality I desperately craved. The problem was that I ultimately did not know what steps I needed to take in order to grow that elusive talent. Thus began my quest to achieve this lofty goal.
I was recently perusing the excellent book "97 Things Every Software Architect Should Know" and read the essay titled "There Is No One-Size-Fits-All Solution"1. In this essay, Stafford discusses the term "contextual sense" drawing from the 1991 book by Eberhardt Rechtin2. To summarize, contextual sense describes the application of experience to solve a difficult problem. The more experience and wisdom you have at your disposal, the more likely you are to navigate to an optimal solution. Truly it is common sense to those that have the required experience, but is indistinguishable from witchcraft for those who are lacking it.
It immediately struck me; I had finally found a proper term to add to my vocabulary to replace the primitive "Spidey Sense"! Once I had supplied a name and meaning to this vague idea, I needed to identify a path to achieving it. I discovered a potential answer in the video "Software Architecture Fundamentals: Understanding the Basics"3, available from O'Reilly Media. In the section entitled "Architecture Soft Skills Part 2", Mark Richards shares his idea of the Knowledge Pyramid. Neal Ford has blogged about this concept on his own website4 and I encourage you to take a look. In that article he explains Mark's concept of the pyramid and how it relates to technical knowledge and experience.
For me the most revealing aspect of this Knowledge Pyramid was the shifting of my own priorities as a professional. For the first 10 years of my career, I was heavily focused on increasing my technical depth, as defined by Mark. In other words, I was trying to actively engage in and have working knowledge of a wealth of different techniques, technologies, and frameworks. However, the amount of technical depth you can acquire is finite, as knowledge grows stale for all but a few extraordinary individuals. As a result, the growth of my technical breadth beyond that depth was organic, bordering on accidental.
My increasing interest in discovering new ideas or technologies over the past few years was exactly what I needed to break out of that pattern and grow my technical breadth. I don't need to know every detail about a framework in order for that knowledge to serve a purpose. All I need to know is what problem it solves and how it's solution is different, or better, than others. With the rapid rate of change in our industry, being able to consume and retain a high-level understanding of new technologies is paramount. This is the most important abstraction I have devised thus far in my career.
The definition of contextual sense can be deceptively simple because it covers the entire breadth of applicable experience. The Principle of Linguistic Relativity5 indicates that our thoughts are defined or shaped by, to some extent, the language in which we speak. Having a better definition for a pivotal concept or set of concepts can help to better define a universe of discourse. Certainly, being able to quickly refer to an entire set of principles and ideas in two simple words is a powerful abstraction. I hope that sharing my meandering path to understanding will provide some value to others.
1Stafford, Randy. "There Is No One-Size-Fits-All Solution." 97 Things Every Software Architect Should Know. Ed. Richard Monson-Haefel. 1st ed. Sebastopol: O'Reilly Media, 2009. 24-25. Print.
2Rechtin, Eberhardt. Systems architecting: creating and building complex systems. Englewood Cliffs, N.J: Prentice Hall, 1991. Print.
3Software Architecture Fundamentals: Understanding the Basics. Perf. Neal Ford and Mark Richards. O'Reilly Media, 2014. Presentation. O'Reilly Media, Mar. 2014. Web. Feb. 2017.
4Ford, Neal. "Knowledge Breadth Versus Depth." Nealford.com. N.p., 08 Sept. 2015. Web. 12 Feb. 2017. <http://nealford.com/memeagora/2015/09/08/knowledge-breadth-versus-depth.html>.
5Wikipedia contributors. "Linguistic relativity." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 28 Jan. 2017. Web. 12 Feb. 2017.