John Ousterhout > Quotes

“Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.”
― John Ousterhout, A Philosophy of Software Design

“Your job as a developer is not just to create code that you can work with easily, but to create code that others can also work with easily.”
― John Ousterhout, A Philosophy of Software Design

“If your code is undergoing review and a reviewer tells you that something is not obvious, don’t argue with them; if a reader thinks it’s not obvious, then it’s not obvious. Instead of arguing, try to understand what they found confusing and see if you can clarify that, either with better comments or better code.”
― John Ousterhout, A Philosophy of Software Design

“Methods containing hundreds of lines of code are fine if they have a simple signature and are easy to read. These methods are deep (lots of functionality, simple interface), which is good.”
― John Ousterhout, A Philosophy of Software Design

“If software developers should always be thinking about design issues, and reducing complexity is the most important element of software design, then software developers should always be thinking about complexity.”
― John Ousterhout, A Philosophy of Software Design

“Most modules have more users than developers, so it is better for the developers to suffer than the users. As a module developer, you should strive to make life as easy as possible for the users of your module, even if that means extra work for you. Another way of expressing this idea is that it is more important for a module to have a simple interface than a simple implementation.”
― John Ousterhout, A Philosophy of Software Design

“specialized code should be cleanly separated from general-purpose code. This can be done by pushing the specialized code either up or down in the software stack.”
― John Ousterhout, A Philosophy of Software Design

“Overall, the best way to reduce bugs is to make software simpler.”
― John Ousterhout, A Philosophy of Software Design

“Unfortunately, I often see smart people who insist on implementing the first idea that comes to mind, and this causes them to underperform their true potential (it also makes them frustrating to work with). Perhaps they subconsciously believe that “smart people get it right the first time,” so if they try multiple designs it would mean they are not smart after all. This is not the case. It isn’t that you aren’t smart; it’s that the problems are really hard! Furthermore, that’s a good thing: it’s much more fun to work on a difficult problem where you have to think carefully, rather than an easy problem where you don’t have to think at all.”
― John Ousterhout, A Philosophy of Software Design

“Good design doesn’t really take much longer than quick-and-dirty design, once you know how.”
― John Ousterhout, A Philosophy of Software Design

“Comments serve as a canary in the coal mine of complexity. If a method or variable requires a long comment, it is a red flag that you don’t have a good abstraction.”
― John Ousterhout, A Philosophy of Software Design

“Sometimes an approach that requires more lines of code is actually simpler, because it reduces cognitive load.”
― John Ousterhout, A Philosophy of Software Design

“I have noticed that the design-it-twice principle is sometimes hard for really smart people to embrace. When they are growing up, smart people discover that their first quick idea about any problem is sufficient for a good grade; there is no need to consider a second or third possibility. This tends to result in bad work habits. However, as these people get older, they get promoted into environments with harder and harder problems. Eventually, everyone reaches a point where your first ideas are no longer good enough; if you want to get really great results, you have to consider a second possibility, or perhaps a third, no matter how smart you are. The design of large software systems falls in this category: no-one is good enough to get it right with their first try.”
― John Ousterhout, A Philosophy of Software Design

“The problem with test-driven development is that it focuses attention on getting specific features working, rather than finding the best design. This is tactical programming pure and simple, with all of its disadvantages. Test-driven development is too incremental: at any point in time, it’s tempting to just hack in the next feature to make the next test pass. There’s no obvious time to do design, so it’s easy to end up with a mess.”
― John Ousterhout, A Philosophy of Software Design

“some might argue that it’s better to focus on today’s needs, building just what you know you need, and specializing it for the way you plan to use it today. If you take the special-purpose approach and discover additional uses later, you can always refactor it to make it general-purpose. The special-purpose approach seems consistent with an incremental approach to software development.”
― John Ousterhout, A Philosophy of Software Design

“The guiding principle for comments is that comments should describe things that aren’t obvious from the code.”
― John Ousterhout, A Philosophy of Software Design

“The best modules are those that provide powerful functionality yet have simple interfaces. I use the term deep to describe such modules.”
― John Ousterhout, A Philosophy of Software Design

“Designing it twice does not need to take a lot of extra time. For a smaller module such as a class, you may not need more than an hour or two to consider alternatives. This is a small amount of time compared to the days or weeks you will spend implementing the class. The initial design experiments will probably result in a significantly better design, which will more than pay for the time spent designing it twice.”
― John Ousterhout, A Philosophy of Software Design

“Even if your particular change doesn’t require refactoring, you should still be on the lookout for design imperfections that you can fix while you’re in the code. Whenever you modify any code, try to find a way to improve the system design at least a little bit in the process. If you’re not making the design better, you are probably making it worse.”
― John Ousterhout, A Philosophy of Software Design

“Thus, you shouldn’t settle for names that are just “reasonably close”. Take a bit of extra time to choose great names, which are precise, unambiguous, and intuitive.”
― John Ousterhout, A Philosophy of Software Design

“Here are a few of of the most important red flags discussed in this book. The presence of any of these symptoms in a system suggests that there is a problem with the system’s design: Shallow Module: the interface for a class or method isn’t much simpler than its implementation (see pp. 25, 110). Information Leakage: a design decision is reflected in multiple modules (see p. 31). Temporal Decomposition: the code structure is based on the order in which operations are executed, not on information hiding (see p. 32). Overexposure: An API forces callers to be aware of rarely used features in order to use commonly used features (see p. 36). Pass-Through Method: a method does almost nothing except pass its arguments to another method with a similar signature (see p. 52). Repetition: a nontrivial piece of code is repeated over and over (see p. 68). Special-General Mixture: special-purpose code is not cleanly separated from general purpose code (see p. 71). Conjoined Methods: two methods have so many dependencies that its hard to understand the implementation of one without understanding the implementation of the other (see p. 75). Comment Repeats Code: all of the information in a comment is immediately obvious from the code next to the comment (see p. 104). Implementation Documentation Contaminates Interface: an interface comment describes implementation details not needed by users of the thing being documented (see p. 114). Vague Name: the name of a variable or method is so imprecise that it doesn’t convey much useful information (see p. 123). Hard to Pick Name: it is difficult to come up with a precise and intuitive name for an entity (see p. 125). Hard to Describe: in order to be complete, the documentation for a variable or method must be long. (see p. 133). Nonobvious Code: the behavior or meaning of a piece of code cannot be understood easily. (see p. 150).”
― John Ousterhout, A Philosophy of Software Design

“Another way of expressing this idea is that it is more important for a module to have a simple interface than a simple implementation.”
― John Ousterhout, A Philosophy of Software Design

“Another example of a deep module is the garbage collector in a language such as Go or Java. This module has no interface at all; it works invisibly behind the scenes to reclaim unused memory. Adding garbage collection to a system actually shrinks its overall interface, since it eliminates the interface for freeing objects. The implementation of a garbage collector is quite complex, but that complexity is hidden from programmers using the language.”
― John Ousterhout, A Philosophy of Software Design

“For most interfaces the informal aspects are larger and more complex than the formal aspects.”
― John Ousterhout, A Philosophy of Software Design

“The best performance improvement is the transition from the nonworking state to the working state.”
― John Ousterhout

“If a system contains adjacent layers with similar abstractions, this is a red flag that suggests a problem with the class decomposition.”
― John Ousterhout, A Philosophy of Software Design

“Change amplification: The first symptom of complexity is that a seemingly simple change requires code modifications in many different places.”
― John Ousterhout, A Philosophy of Software Design

“The second cause of complexity is obscurity. Obscurity occurs when important information is not obvious.”
― John Ousterhout, A Philosophy of Software Design

“In my experience, the sweet spot is to implement new modules in a somewhat general-purpose fashion. The phrase “somewhat general-purpose” means that the module’s functionality should reflect your current needs, but its interface should not. Instead, the interface should be general enough to support multiple uses.”
― John Ousterhout, A Philosophy of Software Design

“All programming requires is a creative mind and the ability to organize your thoughts. If you can visualize a system, you can probably implement it in a computer program.”
― John Ousterhout, A Philosophy of Software Design