Raising the Level of Abstraction

Abstraction is a central concept in software development.
Abstraction is probably our only hope to conquer the ever rising complexity and requirements in current and future systems.

When designing a software system today often there are no physical constraints. The only constraints are intellectual: Is the design understandable, maintainable, what are the effects of future changes ...

Abstraction is supposed to be a tool to do the right choices when designing.
But what is abstraction really? How do you characterize it? How do you measure it?

There seem to be a lot of different notions about how to raise the abstraction level.

Some people talk about nonterminal symbols:

<integer> ::= ['-'] <digit> {<digit>}
<digit> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'

Some people believe in pictures and visuals:

Some people see hope in reducing the signal-to-noise ratio of code:

[...] a lot of Java programs are the boiler plate of controlled structures with very little business logic. It's probably a four or five to one ratio between business logic and boiler plate control structures. So Ruby gives you that conciseness.
You are saying: "Here is the business logic, apply this business logic [...]

-- David Pollak, InfoQ

For me, the third approach is currently the most promising. That's where DDD tries to pull the lever. That's where concepts like the Ubiquitous Language and Domain Specific Languages try to provide value.


And finally remember Joel Spolsky's Law of Leaky Abstractions:

All non-trivial abstractions, to some degree, are leaky.

follow me on twitter, I need some friends :-)