Quotes from Steve McConnell

The concept of modularity is related to information hiding, encapsulation, and other design heuristics. But sometimes thinking about how to assemble a system from a set of black boxes provides insights that information hiding and encapsulation don't, so the concept is worth having in your back pocket.

Object-Oriented Design Heuristics (1996), Arthur Riel

One indication that a routine needs to be broken out of another routine is deep nesting of an inner loop or a conditional. Reduce the containing routine's complexity by pulling the nested part out and putting it into its own routine.

Be critical of classes that contain more than about seven data members. The

If a class contains more than about seven data members, consider whether the class should be decomposed into multiple smaller classes (Riel 1996). You might err more toward the high end of 7±2 if the data members are primitive data types like integers and strings, more toward the lower end of 7±2 if the data members are complex objects.

Classes and routines are first and foremost intellectual tools for reducing complexity. If they're not making your job simpler, they're not doing their jobs.

Implement is a through public inheritance. When a programmer decides to create a new class by inheriting from an existing class, that programmer is saying that the new class is a more specialized version of the older class. The base class sets expectations about how the derived class will operate and imposes constraints on how the derived class can operate (Meyers 1998).

in the vast majority of systems, efficiency isn't critical.

If the derived class isn't going to adhere completely to the same interface contract defined by the base class, inheritance is not the right implementation technique. Consider containment or making a change further up the inheritance hierarchy.

Avoid duplicate code. Undoubtedly the most popular reason for creating a routine is to avoid duplicate code. Indeed, creation of similar code in two routines implies an error in decomposition. Pull the duplicate code from both routines, put a generic version of the common code into a base class, and then move the two specialized routines into subclasses.

inheritance is a powerful tool for reducing complexity because a programmer can focus on the generic attributes of an object without worrying about the details. If a programmer must be constantly thinking about semantic differences in subclass implementations, then inheritance is increasing complexity rather than reducing it.

You save time when you don't need to have an awards ceremony every time a C statement does what it's supposed to. Moreover

defect corrections have more than a 50 percent chance of being wrong the first time

Hurrying to solve a problem is one of the most time-ineffective things you can do.

There is no code so big, twisted, or complex that maintenance can't make it worse.

The underlying message of all these rules is that inheritance tends to work against the primary technical imperative you have as a programmer, which is to manage complexity. For the sake of controlling complexity, you should maintain a heavy bias against inheritance.

One key to successful programming is avoiding arbitrary variations so that your brain can be free to focus on the variations that are really needed.

The process is called estimation, not exactimation. —Phillip Armour

The gap between the best software engineering practice and the average practice is very wide—perhaps wider than in any other engineering discipline. A tool that disseminates good practice would be important. — Fred Brooks

To experiment effectively, you must be willing to change your beliefs based on the results of the experiment

When in doubt, use brute force.

Programmers who program into a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.

If you can't figure out how to use a class based solely on its interface documentation, the right response is not to pull up the source code and look at the implementation. That's good initiative but bad judgment. The right response is to contact the author of the class and say I can't figure out how to use this class.

The right response for the class author is to check out the class-interface file, modify the class-interface documentation, check the file back in, and then say See if you can understand how it works now.