Patterns of Software: Tales from the Software Community -- Book by Richard P. Gabriel; Oxford University Press, 1998
Preface
The essays in this book started out as a series of columns for the Journal of ObjectOriented Programming. I was trying to model myself somewhat after Samuel Johnson, and the series was aimed at being the digital age's equivalent of The Rambler. I'm certain I didn't succeed in matching Johnson's wit and style, but I matched at least two of his characteristics--procrastination and laziness. Johnson was well known for writing his essays right up to the deadline, often keeping the publisher's runner waiting for the manuscript as Johnson completed it. In fact, you can notice the effect in many of his essays: An essay starts to make an argument in one direction (corresponding to the first sheets Johnson handed the runner) and then the argument shifts radically or even to the opposite pole as Johnson continued writing and thinking--but revision of the earlier parts was impossible, as it was being typeset for final copy as Johnson pondered.

For my essays I chose the stance of critic at large. In this role I attempted to examine topics of interest to the object-oriented programming community from the point of view of someone whose experience has always had a sour component-this will be the subject of some of the essays. I had been working in the object-oriented field for seven years when I started writing them. Object-oriented programming has a very long history, which the newly initiated sometimes finds surprising. First designed primarily as a means of simulation, later as programming languages for children, object-oriented languages have become nearly mainstream, largely as a means of achieving reuse and productivity. You see, the history of computing is replete with attempts at making programming easier and, more important, cheaper.

Current software makes machines of a sort previously unknown and with capabilities unheard of, partly because there can be built into them some small portion of reason and consideration and intelligent--rather than merely mechanical--reaction. Automo-biles can run for dozens of thousands of miles without tuning because their internal operation is governed by software--it's almost more likely that your car can be fixed by a Ph.D. in computer science than by your grandfather's auto mechanic. When we start cataloging the gains in tools sitting on a computer, the benefits of software are amazing. But, if the benefits of software are so great, why do we worry about making it easier--don't the ends pay for the means? We worry because making such software is extraordinarily hard and almost no one can do it--the detail is exhausting, the creativity required is extreme, the hours of failure upon failure requiring patience and persistence would tax anyone claiming to be sane. Yet we require that people with such characteristics be found and employed and employed cheaply. We've tried to make programming easier, with abstraction as a tool, with higher-level programming languages, faster computers, design methodologies, with rules of thumb and courses and apprenticeships and mentoring, with automatic programming and artificial intelligence. Compilers, debuggers, editors, programming environments. With structured programming and architectural innovations.

With object-oriented programming. But programming still requires people to work both alone and in teams, and when people are required to think in order to achieve, inherent limitations rule. Object-oriented programming--which is merely a set of concepts and programming languages to support those concepts--cannot remove the need to think hard and to plan things, to be creative and to overcome failures and obstacles, to find a way to work together when the ego says not to, that the failures are too many and too pervasive. Reuse, productivity, reliability--these are values prized by managers and moneymakers. Software creators are usually called engineers, a connotation that usually brings to mind a person who applies well-known principles and methods to create variations on known themes. For example, a bridge builder is an engineer who uses a long list of known techniques to erect a structure to traverse rivers, chasms, and rough terrain while supporting a certain load while withstanding natural forces like wind and earthquakes.

Even though the word engineer comes from the same basic root as ingenuity does, the feeling one gets when hearing the word is of careful, detailed, nearly plodding predictability of work. This makes sense to a degree because engineering disciplines frequently have handbooks from which they work that prescribe a series of rules and principles and ways of solving problems according to a long tradition and experience. For instance, bridge builders have centuries of experience bridge building to draw upon.