What about Object-Oriented Programming?

will a brass bullet do?

Brook’s asks this about the adoption of object-oriented programming languages in a follow up to “No Silver Bullet”, “No Silver Bullet Revisited”. The answer he arrives at is no. I agree. Object-oriented programming languages had no chance of being a silver bullet. There are three reasons. First, a tool, no matter how great, does not make a great craftsman. Second, designing great software requires deep domain expertise. Lastly, most software organizations are not incentivized to invest for the long term and good design(object-oriented or otherwise) is something you pay for up front that pays you back later.

Programmers were introduced to object-oriented programming by teaching them to use a programming language instead of teaching them how to design. Brook’s quoting DL Parnas:

The answer is simple. It is because [O-O] has been tied to a variety of complex languages. Instead of teaching people that O-O is a type of design, and giving them design principles, people have taught that O-O is the use of a particular tool. We can write good or bad programs with any tool. Unless we teach people how to design, the languages matter very little. The result is that people do bad designs with these languages and get very little value from them. If the value is small, it won’t catch on.

This still goes on today. I learned that I was doing object-oriented programming by using the Ruby programming language. I was 7 years into my career when I learned what an object was by reading On Understanding Data Abstraction, Revisited by William Cook. I don’t think most programmers could separate object-oriented design from the use of particular programming language.

Even if programmers had been trained in design principles along with the languages, it’s not enough. The insightful, maintainable, and extensible design won’t come from principles and a language. The programmers need to know the domain. The best object-oriented programs are object-oriented programming languages. Brook’s quotes James Coggins complaining about this:

The problem is that programmers in O-O have been experimenting in incestuous applications and aiming low in abstraction, instead of high. For example, they have been building classes such as linked-list or set instead of classes such as user-interface or radiation beam or finite-element model.

The programmers are writing good abstractions for the domain they know best, programming. Programmers understand the requirements for linked-lists and sets better than anyone. To write a great abstraction for radiation beam, user-interface, or finite-element, the programmers would have to understand physics, users, or differential equations. Even if the programming team had physicists, users, and mathematicians on the team, coming up with a design would take time. Most programming organizations don’t value design enough to take the time.

Design compounds. You pay for it now but don’t see the benefits till later. Brook’s summarizes this as “Front-loaded costs, down-stream benefits”.

Front-loaded costs, down-stream benefits. My own belief is that object-oriented techniques have a peculiarly severe case of a malady that characterizes many methodological improvements. The up-front costs are very substantial—primarily retraining programmers to think in a quite new way, but also extra investment in fashioning functions into generalized classes. The benefits, which I think are real and not merely putative, occur all along the development cycle; but the big benefits pay off during successor building, extension, and maintenance activities. Coggins says, “Object-oriented techniques will not make the first project development any faster, or the next one. The fifth one in that family will go blazingly fast.”

Most of the places I’ve worked have front-loaded the benefits and down-streamed the costs. Speed is rewarded above all else. Design mistakes are built upon or around instead of fixed. By the time it becomes obvious to even the non-technical people that the software has some fundamental problems, it’ usually too late.

Object-oriented programming languages were never going to automatically lead to good designs. The arrangement and composition of a software system doesn’t come fully formed out of a standard library. Programmers would also have to learn design principles, the domain and be in an environment that incentivizes the investment.