Software Abstractions ,Logic, Language, and Analysis by Daniel Jackson

Software is built on abstractions. Pick the right ones, and programming 
will flow naturally from design; modules will have small and simple in-terfaces; and new functionality will more likely fit in without extensive 
reorganization. Pick the wrong ones, and programming will be a series 
of nasty surprises: interfaces will become baroque and clumsy as they 
are  forced  to  accommodate  unanticipated  interactions,  and  even  the 
simplest  of  changes  will  be  hard  to  make.  No  amount  of  refactoring, 
bar  starting  again  from  scratch,  can  rescue  a  system  built  on  flawed 
concepts.
Abstractions  matter  to  users  too.  Novice  users  want  programs  whose 
abstractions  are  simple  and  easy  to  understand;  experts  want  abstrac-tions that are robust and general enough to be combined in new ways. 
When  good  abstractions  are  missing  from  the  design,  or  erode  as  the 
system  evolves,  the  resulting  program  grows  barnacles  of  complexity. 
The user is then forced to master a mass of spurious details, to develop 
workarounds, and to accept frequent, inexplicable failures.

The  core  of  software  development,  therefore,  is  the  design  of  abstrac-tions. An abstraction is not a module, or an interface, class, or method; 
it is a structure, pure and simple—an idea reduced to its essential form. 
Since the same idea can be reduced to different forms, abstractions are 
always, in a sense, inventions, even if the ideas they reduce existed be-fore in the world outside the software. The best abstractions, however, 
capture their underlying ideas so naturally and convincingly that they 
seem more like discoveries.
The  process  of  software  development  should  be  straightforward.  First, 
you  design  the  abstractions,  from  a  careful  consideration  of  the  prob-lem  to  be  solved  and  its  likely  future  variants.  Then  you  develop  its 
embodiments in code: the interfaces and modules, data structures and 
algorithms (or in object-oriented parlance, the class hierarchy, datatype 
representations, and methods).
Unfortunately,  this  approach  rarely  works.  The  problem,  as  Bertrand 
Meyer once called it, is wishful thinking. You come up with a collection 
of abstractions that seem to be simple and robust. But when you imple-ment them, they turn out to be incoherent and perhaps even inconsis