Implementation inheritance... is a bad idea that makes software harder to manage and reuse. It binds the implementations of classes together so that neither class can be understood without the other: a subclass cannot be understood without knowing how the inherited methods are implemented in its superclass, and a superclass cannot be understood without knowing how its methods are inherited in subclasses. In a complex class hierarchy, no individual class can be understood without understanding all the other classes in the hierarchy.

Nonetheless, object oriented programming does provide at least two useful features. The first is encapsulation: objects combine together data and code in a way that hides implementation details. The second useful feature is interface inheritance, which refers to classes that provide the same methods and APIs even though they have different implementations. This makes the classes interchangeable, which encourages reuse.

Denial that the expression problem exists is a common symptom of overzealous functional or object-oriented dogmatism.

"Raise your quality standards as high as you can live with, avoid wasting your time on routine problems, and always try to work as closely as possible at the boundary of your abilities. Do this, because it is the only way of discovering how that boundary should be moved forward."

Unlike most MVC-style configurations, Passive View results in no dependencies between view and model.

Upon further study and reflection, I decided that pattern that was here under the name "Model View Presenter" needed to be split, so I have separated it into Supervising Controller and Passive View.

Presenter First is a software development approach that combines the ideas of the model–view–presenter (MVP) design pattern, test-driven development, and Feature-driven development.

Presenter First concentrates on transforming each of a customer's requirements into a well tested, working feature as quickly and with as much correlation to the customer's story language (requirement) as possible. The language of the story or requirement is used to directly guide development of the feature – even naming the modules and function calls. As a consequence, the feature implementation tends to closely represent the customer's desire with little extraneous or unneeded functionality. The language of the source code also corresponds closely to the customer's stories.

[The MIT/Stanford style of design] can be captured by the phrase ``the right thing.'' To such a designer it is important to get all of the following characteristics right:

Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.

Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed.

Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.

Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

...I will call the use of this philosophy of design the "MIT approach."... However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing...

...The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.