“I asked Joe to write a simple bit of code to do <xyz>. It should have taken a few hours, maybe a day at worst. He took several days, he wrote a general framework that was far more complicated than we needed. Why does he keep over-engineering his code?”

It could be that Joe is an Abstract Oriented Programmer. Here’s a few snowclones…

If you often over-engineer your software, you might just be an Abstract Oriented Programmer.

If you spend more time thinking about tomorrow’s problems than today’s, you might just be an Abstract Oriented Programmer.

If you love looking for deeper patterns, get thrills from unconscious insight or talk in analogies, you might just be an Abstract Oriented Programmer.

Necessity of Abstraction

There are few applied professions that deal as heavily in abstractions as software development. Programming languages, data representations, graphical displays, control flows and so on are abstractions of the real world, abstractions of underlying hardware and often abstractions of abstractions.

The extraordinary performance growth of CPU’s (following Moore’s Law) demands abstractions. When I started out programming it was on computers with CPUs that had a transistor count in the thousands. The Motorola 6800 had 4,100 transistors clocked at 1-2MHz. The Zilog Z80 had 8,500 transistors clocked at 2-8MHz. Understanding CPU registers, interrupts and other quasi-physical details helped a great deal if you wanted to make these computers excel at something useful.

The latest mass-production CPUs have a billion or so transistors. Take the Intel Core i7 series which has around 1 Billion transistors and a clock speed in the 2-3.5Ghz range.

That’s roughly a billion times more computational capacity in 30 years. Human evolution hasn’t kept up. So we need to use a great deal of that increased CPU power to take advantage of that increased CPU power. That’s where compilers, virtual machines, advanced graphics, optimizers of many varieties, higher level programming languages and other programmer tools come in. There are layers upon layers of abstraction between the hardware and the software we write today. Indeed, they are a necessity.

So it’s not surprising that programming attracts people who are natural abstract thinkers … or perhaps that abstract thinkers are more likely to enjoy and succeed in programming.

But it can be easy to forget that not all people are abstract thinkers, or conclude that all programmers are abstract oriented, or incorrectly conclude that abstract thinking is always the best mode of thought.

Abstract Thinking

Some definitions:

Abstract (adjective)

Considered apart from concrete existience, e.g. facts

Not applied or practical; theoretical

Abstraction (noun)

The process of formulating generalized ideas or concepts by extracting common qualities or patterns from specific examples

Abstractions are by definitions a simplification of information by taking lots of examples and condensing them into a pattern.

Some people naturally think in abstractions in contrast to others who tend to think more in the specific facts. Speaking abstractly, it’s about how people process information.

Consider the Myers Briggs Type Indicator which is widely used in business. The MBTI has four personality distinctions of which the “Intuitive” vs. “Sensing” (N vs. S in MBTI jargon) corresponds to Abstract vs. Concrete thinking. (There are other psychological assessments that have similar distinctions.)

The following tables lists some some of the tendencies exhibited by abstract and concrete thinkers.

Since most people adapt their behavior somewhat according to circumstance you can also read the table as tendencies when you are in an Abstract or Concrete frame of mind though most theories posit that you have a preferred tendency.

Trusts information that is more abstract or theoretical and associations/patterns

Likes information that is in the present, tangible and concrete and understood by the five senses

Trusts flashes of insight bubbling up from the unconscious

Distrusts hunches that seem to come out of nowhere

Joe Revisited

Let’s return to the story of Joe at the start of this post in which he over-engineers code. As an abstract oriented programmer there is a clear logic.

Today’s problem is X.

X is an example of a broader class of issues that also includes Y and Z.

Since we might encounter Y and Z later I should write code that solves X, Y and Z.

But in the converse, asking Joe to solve only X when he knows it might fail in the future on problems Y and Z can leave him frustrated or concerned that he’ll be blamed in the future.

Context matters. Thinking ahead can make you a hero. Thinking ahead can make you a burden. Focussing on the immediate problem at hand can make you a hero … or a burden.

The trick is knowing what approach to take in each different circumstance: put simply, adapt.

And it can be important to discuss or confirm your approach with colleagues: simply, communicate.

Here are some common observations I’ve heard about Abstract Oriented Programmers…

Abstract Oriented Programmers

Compliments

Complaints

She takes on poorly defined jobs and does a great job.

He thinks deeply about the problem and puts together elegant solutions.

She’s always trying different techniques and looking for better approaches.

The team (of AOPs) comes up these unexpected by great ideas.

He’s always solving tomorrow’s problems. I can’t get a quick fix when I need one.

Too often she over-engineers her code. Sometimes I need her to just hack quickly.

He keeps trying to re-engineer all our code. The legacy code is working. Just leave it alone.

Why won’t she follow the process?!

Our team (of AOPs) discussions stray away from the problem. Sure, they are interesting discussions but we just need to focus on the problem at hand.

…and Concrete Oriented Programmers

Concrete Oriented Programmers

Compliments

Complaints

He doesn’t speculate. He deals with the problem at hand and gets it done.

She knows our processes and follows them.

He shows a lot of common sense.

This team (of COPs) is grounded in what they can and should achieve.

His code solves a narrow problem. It passes the tests but fails in the real world.

Her code is inflexible and unmaintainable. Each time we add a feature we have to re-engineer the code.

He didn’t think through the problem. His code simply wasn’t written to last.

Mini Test

List A. How many of these describe you well? (It’s best not to overthink your answer. Go with your first impression.)

You are more interested in a general idea than in the details of its realization

You often think about humankind and its destiny

You easily see the general principle behind specific occurrences

You often contemplate about the complexity of life

You think that almost everything can be analyzed

You easily understand new theoretical principles

You often spend time thinking of how things could be improved

You easily perceive various ways in which events could develop

List B. How many of these describe you well?

You get bored if you have to read theoretical books

You tend to rely on your experience rather than on theoretical alternatives

It’s essential for you to try things with your own hands

When considering a situation you pay more attention to the current situation and less to a possible sequence of events

As a rule, current preoccupations worry you more than your future plans

If you agree with more items in List A than List B then you might be Abstract Oriented.

Conversely, if you agree with items in List B more than List A then you might be the Sensing/Concrete type.

[A couple of cautions. First, type is not destiny. Life often requires us to adapt our behavior for family, work and friends etc. Second, it follows that depending upon context you might answer the questions differently. Third, this is about describing our internal thinking and it’s difficult to be objective about that.]

Adapting Thinking

Years ago I heard a good analogy. You can be right-handed or left-handed. Most people have a preference and a few are ambidextrous. Just because somebody strongly prefers their right hand doesn’t mean their left hand is useless. Plus, some tasks require use of a particular hand: try using right-handed scissors with your left hand, or driving a manual car using the wrong hand on the gear stick.

We all have the ability to deal in facts and patterns but tend to have a relative strength. Similarly, there are tasks that favor each kind of thinking. It is my experience that programmers are stronger when they understand what their natural thinking mode is but learn to adapt according to the context.

Some examples that favor abstract and concrete thinking (and these are generalizations).

User interface development can require attention to a multitude of details.

Specifications benefit from broad thinking but can be strengthened with specific examples (as tests of generalizations; making it easier to read by providing concrete examples; ensuring that the generalizations don’t drift away from reality).

Non-programming colleagues and customers might be concrete thinkers. An abstractionist talking to a “concretist” can be (mis-)perceived as having their head in the clouds. If you’re an abstractionist it is a good skill to communicate to others in their preferred language of specifics.

So it I is not my intention to state a preference for abstract or concrete thinking. Instead I am advocating self-awareness and learning flexibility in thinking and communication.

Being a strong abstractionist myself, I must conclude with a great piece of abstract thought.

“All generalizations are false, including this one.” Mark Twain

And Mark Twain was an Abstract Oriented Writer.

Cheers,
Psygrammer – Andrew Hunt

Share this:

Like this:

Related

6 Comments on “Abstract Oriented Programmer”

When you work with an abstract oriented programmer you sometimes want to say “Just do it!”. It’s difficult to say with certainty that the functionality you’re being asked to implement is throwaway or that you won’t be asked later to build on that … but at least there’s a structure there that can easily be built on.
With a concrete oriented programmer, you have to be exceptionally specific otherwise the code will just about do what’s required but there’s no way it will do more.
Personally I can see how important it is for a manager to understand which type of programmer he/she is dealing with otherwise there’s no way the results will meet the expectations.

Margaret, I fully agree that managers gain from knowing which of their programmers are more abstract-oriented or concrete-oriented.
I think also that programmers gain from knowing their own tendency AND being able to adapt their behavior.
When a team has programmers from different points on the spectrum it can be powerful when each plays to their strength OR create frustration when the differences cause friction. Awareness of the differences should reduce the friction.

A pile of abstractions produces an “organised” mess in the code as efficiently as hacking produces “unorganised” mess. The result is the same – unreadable and unmanageable software. Whether is was an abstract orientation or concrete approach if in the end we have a bad code then it had happened not because of orientation; it was caused by something more fundamental. Could it be a self-centric attitude? If it is the cause then the task of adaptation of one’s own thinking becomes very difficult if possible at all.

Another one is code flexibility which is generally perceived as a good thing. It is good only to a certain extent. It is not possible to change a “liquid” code as it is not possible to carve from water.

Thank you for the comments Dmitri. Could you expand on what you mean by “self-centric attitude”?

An orientation to abstract or concrete programming does not imply that you are good at abstract or concrete programming — only that it’s the way that you tend to think. To reuse the left/right hand analogy, being left-handed does not imply that you are dexterous with that hand — only that you prefer it. So, I think you are totally right that you can be either abstract or concrete and still create messy code.

I would argue, however, that for most software challenges of sufficient size and complexity that the abstract thinking will be an advantage. Most programmers are strongly abstract (and I suspect that even the more concrete programmers are still more abstract than the average population). Abstractions tend to create better modularization, better APIs, generally better structure etc. Conversely I suspect that “spaghetti code” tends to be created by more concrete programmers.

>> Balance is the key. But how can we get it right?

I agree also that, as you put it, “balance is key” in determining how much code flexibility is needed. The balance will depend upon context — how much time do I have, is the code once-time-use or will it be the foundation of our product for years, is it rarely used by customers or a major feature, how often has it failed etc. Perversely, a strongly abstract thinker might be less pragmatic given the constraints of many software development environments (tight schedules, legacy code etc)

So the case that I arguing overall through this blog is that (a) Programmers do have different tendencies that reflect their personality, (b) Programmers benefit from self-awareness of that style and consciousness of alternative styles, (c) with self-awareness there is a greater capacity to ADAPT according to the context and so do a better job.

Conversely, with less self-awareness there is a tendency to assume that “my natural way is the right way”. Perhaps it’s the psygrammer paradox I wrote about earlier, but I think that greater self-awareness for a programmer can mean than personality has less adverse impact on their work.

>>what you mean by “self-centric attitude”
Andrew, I mean there the opposite to what you call “self-awareness”. “I know that my way is the best one, hence everything else is wrong” – this is an extreme case which we see way too often unfortunately.

[…] of a stimulating exploration of ideas. It seems that, like me, they were Type P and were also Abstract Oriented Programmers (that’s the perfect combination for everlasting technical discussion). The COO immediately […]