Who Thinks Abstractly?

I think my word for the year is 'abstraction.' Where would we be without it? Every major development in programming languages, like almost every major development in the world, involves a new layer of abstraction. For instance, assembly provides a layer of abstraction so you don't have to program in 0's and 1's. (Aren't you glad?) OO programming's tenet of encapsulating behavior and data allows you to abstract away the implementation. N-Tier application development lets you abstract away different layers of code. Web services allow you to abstract away domain languages.

The 0's and 1's are still there--somewhere. And maybe your system would run faster if you optimized the byte code. But it's probably not worth the effort. For a performance trade-off, you get a huge productivity boost. And programming becomes a whole lot more fun. It becomes more about concepts and systems and less about abstruse technical matters. I can't even think of the last time I had to worry about memory allocation.

It's easy to chart the rise of abstraction against the popularity of UML, a system of diagrammatic standards for modelling code (which is itself a model). UML has become necessary in order to deal with the interactions of our ever-more-complex systems.

Phillipe Krutchen's 4+1 view

I've been shoring up my understanding of UML, and one thing I never really thought about was how it provides a set of windows onto systems. UML lets you see the use cases, logic, processes, development, and physical makeup of a system.  Though certain models have become very popular (such as sequence diagrams for modelling messaging systems), which particular one you need depends on the problem you're trying to solve.

You can look at a system from the perspective of:

• A user (use case diagrams)
• A business analyst (activity diagrams)
• A developer (class, sequence, communication, and timing diagrams)
• An architect (component, package, and state machine diagrams)
• A systems architect (deployment diagrams)

UML is nice because it standardizes the napkin drawings we tend to do naturally. It gives us a common vocabulary we can all utilize. And it's not hard to learn.

Hot or not?

But I think developers worry that UML--or something like it--could fulfil the dream of managers everywhere: removing programmers from the picture entirely. Programming has changed drastically since I first started coding, and it's going to change a lot more before I kick the bucket. It's become much more about the interaction between technologies (stacks, libraries, and third party tools) and systems (services, ETL, and domains).

I don't think the need for systems thinkers is going anywhere anytime soon. We'll always need people who can grasp the vocabulary and design of systems and who can chart the ways they should interact and change. But what's really important is understanding the points where systems break down.

In the early 1800's the philosopher GWF Hegel posed the question, Who Thinks Abstractly?  His answer: commoners, not lords and ladies. Lowly folk accept concepts at face value. In the case of a murder trial, for example, all they care about is the fact that someone has been deemed a murderer. It doesn't matter that mommy never loved them or that a bad situation got of hand--they must be hanged.

But particularities do matter, as lords and ladies, who were afraid to label anyone a murder, understood. People judged murders are more than just murderers. That's why we have so many categories of murder. Unfortunately, while lords and ladies understood particularities, they weren't good at seeing forests for trees.

Hegel's dialectic: a model for thinking that undermines the possibility of models

Hegel's main idea is that we need to balance the use of systems of abstractions with an attention to messy reality.

Technology solutions are abstractions just like the concept of murder. And like all abstractions, they don't always do the work they were designed to do. Similarly, business rules can become too rigid to capture the ways business really happens. Systems (whether conceptual or technological) are powerful because they provide a vocabulary that lets us abstract away and control the complexities of reality. But those complexities remain.

Almost anyone who has developed software has faced the tradeoff between creating an elegant system and automating a process that has more exceptions than can be counted. This is why translation is so difficult--language as it is spoken and written always outstrips grammatical rules and dictionary definitions. This struggle between rules and reality will never end.

IQ has increased over time, and jobs have become more and more about systems. If you asked someone what a market was a hundred years ago, they'd point to a physical market rather than describe a system of exchange. Everyone needs to understand abstract concepts and systems today, but we also need people who can understand the particular situations where those systems fail. Whether or not we will have people writing OO code 20 years from now, we'll still need developers who can see the edges of their systems and analysts who can see their box-and-line diagrams for the abstractions they really are.