(Ebook) A Philosophy of Software Design, 2nd Edition

by John K. Ousterhout ISBN 9781732102217, 173210221X

online version

Available at ebooknice.com
( 4.8/5.0 ★ | 308 downloads )

https://ebooknice.com/product/a-philosophy-of-software-design-2nd-
edition-58580286
 (Ebook) A Philosophy of Software Design, 2nd Edition by John
K. Ousterhout ISBN 9781732102217, 173210221X Pdf Download

EBOOK

Available Formats

■ PDF eBook Study Guide Ebook

EXCLUSIVE 2025 EDUCATIONAL COLLECTION - LIMITED TIME

INSTANT DOWNLOAD VIEW LIBRARY

Here are some recommended products that might interest you.
You can download now and explore!

(Ebook) A Philosophy of Software Design by Ousterhout, John K ISBN

9781732102200, 1732102201

https://ebooknice.com/product/a-philosophy-of-software-design-11917402

ebooknice.com

(Ebook) Biota Grow 2C gather 2C cook by Loucas, Jason; Viles, James

ISBN 9781459699816, 9781743365571, 9781925268492, 1459699815,
1743365578, 1925268497

https://ebooknice.com/product/biota-grow-2c-gather-2c-cook-6661374

ebooknice.com

(Ebook) Cambridge IGCSE and O Level History Workbook 2C - Depth Study:

the United States, 1919-41 2nd Edition by Benjamin Harrison ISBN
9781398375147, 9781398375048, 1398375144, 1398375047

https://ebooknice.com/product/cambridge-igcse-and-o-level-history-
workbook-2c-depth-study-the-united-states-1919-41-2nd-edition-53538044

ebooknice.com

(Ebook) Matematik 5000+ Kurs 2c Lärobok by Lena Alfredsson, Hans

Heikne, Sanna Bodemyr ISBN 9789127456600, 9127456609

https://ebooknice.com/product/matematik-5000-kurs-2c-larobok-23848312

ebooknice.com
(Ebook) SAT II Success MATH 1C and 2C 2002 (Peterson's SAT II Success)
by Peterson's ISBN 9780768906677, 0768906679

https://ebooknice.com/product/sat-ii-success-
math-1c-and-2c-2002-peterson-s-sat-ii-success-1722018

ebooknice.com

(Ebook) Clean Architectures in Python: A practical approach to better

software design, 2nd Edition by Leonardo Giordani

https://ebooknice.com/product/clean-architectures-in-python-a-
practical-approach-to-better-software-design-2nd-edition-46463870

ebooknice.com

(Ebook) Master SAT II Math 1c and 2c 4th ed (Arco Master the SAT
Subject Test: Math Levels 1 & 2) by Arco ISBN 9780768923049,
0768923042

https://ebooknice.com/product/master-sat-ii-math-1c-and-2c-4th-ed-
arco-master-the-sat-subject-test-math-levels-1-2-2326094

ebooknice.com

(Ebook) Clean Architectures in Python: A practical approach to better

software design, 2nd Edition (2023 Update) by Leonardo Giordani

https://ebooknice.com/product/clean-architectures-in-python-a-
practical-approach-to-better-software-design-2nd-
edition-2023-update-50725724
ebooknice.com

(Ebook) Software Development, Design and Coding: With Patterns,

Debugging, Unit Testing, and Refactoring, 2nd Edition by John F.
Dooley ISBN 9781484231524, 9781484231531, 148423152X, 1484231538

https://ebooknice.com/product/software-development-design-and-coding-
with-patterns-debugging-unit-testing-and-refactoring-2nd-
edition-7382818
ebooknice.com
A Philosophy of Software Design

John Ousterhout
Stanford University
A Philosophy of Software Design
by John Ousterhout

Copyright © 2018-2021 John K. Ousterhout

All rights reserved. No part of this book may be reproduced, in any form or by any means,
without permission in writing from the author.
Published by Yaknyam Press, Palo Alto, CA.

Cover design by Pete Nguyen and Shirin Oreizy (www.hellonextstep.com).

Printing History:
April 2018: First Edition (v1.0)
November 2018: First Edition (v1.01)
July 2021: Second Edition (v2.0)

ISBN 978-1-7321022-1-7

Digital book(s) (epub and mobi) produced by Booknook.biz.

Contents

Preface

1 Introduction
1.1 How to use this book

2 The Nature of Complexity

2.1 Complexity defined
2.2 Symptoms of complexity
2.3 Causes of complexity
2.4 Complexity is incremental
2.5 Conclusion

3 Working Code Isn’t Enough

3.1 Tactical programming
3.2 Strategic programming
3.3 How much to invest?
3.4 Startups and investment
3.5 Conclusion

4 Modules Should Be Deep

4.1 Modular design
4.2 What’s in an interface?
4.3 Abstractions
4.4 Deep modules
4.5 Shallow modules
4.6 Classitis
4.7 Examples: Java and Unix I/O
 4.8 Conclusion

5 Information Hiding (and Leakage)

5.1 Information hiding
5.2 Information leakage
5.3 Temporal decomposition
5.4 Example: HTTP server
5.5 Example: too many classes
5.6 Example: HTTP parameter handling
5.7 Example: defaults in HTTP responses
5.8 Information hiding within a class
5.9 Taking it too far
5.10 Conclusion

6 General-Purpose Modules are Deeper

6.1 Make classes somewhat general-purpose
6.2 Example: storing text for an editor
6.3 A more general-purpose API
6.4 Generality leads to better information hiding
6.5 Questions to ask yourself
6.6 Push specialization upwards (and downwards!)
6.7 Example: editor undo mechanism
6.8 Eliminate special cases in code
6.9 Conclusion

7 Different Layer, Different Abstraction

7.1 Pass-through methods
7.2 When is interface duplication OK?
7.3 Decorators
7.4 Interface versus implementation
7.5 Pass-through variables
7.6 Conclusion
8 Pull Complexity Downwards
8.1 Example: editor text class
8.2 Example: configuration parameters
8.3 Taking it too far
8.4 Conclusion

9 Better Together Or Better Apart?

9.1 Bring together if information is shared
9.2 Bring together if it will simplify the interface
9.3 Bring together to eliminate duplication
9.4 Separate general-purpose and special-purpose code
9.5 Example: insertion cursor and selection
9.6 Example: separate class for logging
9.7 Splitting and joining methods
9.8 A different opinion: Clean Code
9.9 Conclusion

10 Define Errors Out Of Existence

10.1 Why exceptions add complexity
10.2 Too many exceptions
10.3 Define errors out of existence
10.4 Example: file deletion in Windows
10.5 Example: Java substring method
10.6 Mask exceptions
10.7 Exception aggregation
10.8 Just crash?
10.9 Taking it too far
10.10 Conclusion

11 Design it Twice

12 Why Write Comments? The Four Excuses

12.1 Good code is self-documenting
 12.2 I don’t have time to write comments
12.3 Comments get out of date and become misleading
12.4 All the comments I have seen are worthless
12.5 Benefits of well-written comments
12.6 A different opinion: comments are failures

13 Comments Should Describe Things that Aren’t Obvious from the

Code
13.1 Pick conventions
13.2 Don’t repeat the code
13.3 Lower-level comments add precision
13.4 Higher-level comments enhance intuition
13.5 Interface documentation
13.6 Implementation comments: what and why, not how
13.7 Cross-module design decisions
13.8 Conclusion
13.9 Answers to questions from Section 13.5

14 Choosing Names
14.1 Example: bad names cause bugs
14.2 Create an image
14.3 Names should be precise
14.4 Use names consistently
14.5 Avoid extra words
14.6 A different opinion: Go style guide
14.7 Conclusion

15 Write The Comments First

15.1 Delayed comments are bad comments
15.2 Write the comments first
15.3 Comments are a design tool
15.4 Early comments are fun comments
 15.5 Are early comments expensive?
15.6 Conclusion

16 Modifying Existing Code

16.1 Stay strategic
16.2 Maintaining comments: keep the comments near the code
16.3 Comments belong in the code, not the commit log
16.4 Maintaining comments: avoid duplication
16.5 Maintaining comments: check the diffs
16.6 Higher-level comments are easier to maintain

17 Consistency
17.1 Examples of consistency
17.2 Ensuring consistency
17.3 Taking it too far
17.4 Conclusion

18 Code Should be Obvious

18.1 Things that make code more obvious
18.2 Things that make code less obvious
18.3 Conclusion

19 Software Trends
19.1 Object-oriented programming and inheritance
19.2 Agile development
19.3 Unit tests
19.4 Test-driven development
19.5 Design patterns
19.6 Getters and setters
19.7 Conclusion

20 Designing for Performance

20.1 How to think about performance
 20.2 Measure before (and after) modifying
20.3 Design around the critical path
20.4 An example: RAMCloud Buffers
20.5 Conclusion

21 Decide What Matters

21.1 How to decide what matters?
21.2 Minimize what matters
21.3 How to emphasize things that matter
21.4 Mistakes
21.5 Thinking more broadly

22 Conclusion

Index

Summary of Design Principles

Summary of Red Flags

Preface

People have been writing programs for electronic computers for more than
80 years, but there has been surprisingly little conversation about how to
design those programs or what good programs should look like. There has
been considerable discussion about software development processes such
as agile development and about development tools such as debuggers,
version control systems, and test coverage tools. There has also been
extensive analysis of programming techniques such as object-oriented
programming and functional programming, and of design patterns and
algorithms. All of these discussions have been valuable, but the core
problem of software design is still largely untouched. David Parnas’
classic paper “On the Criteria to be used in Decomposing Systems into
Modules” appeared in 1971, but the state of the art in software design has
not progressed much beyond that paper in the ensuing 45 years.
The most fundamental problem in computer science is problem
decomposition: how to take a complex problem and divide it up into pieces
that can be solved independently. Problem decomposition is the central
design task that programmers face every day, and yet, other than the work
described here, I have not been able to identify a single class in any
university where problem decomposition is a central topic. We teach for
loops and object-oriented programming, but not software design.
In addition, there is a huge variation in quality and productivity among
programmers, but we have made little attempt to understand what makes
the best programmers so much better or to teach those skills in our classes.
I have talked with several people I consider to be great programmers, but
most of them had difficulty articulating specific techniques that give them
their advantage. Many people assume that software design skill is an
innate talent that cannot be taught. However, there is quite a bit of
scientific evidence that outstanding performance in many fields is related
more to high-quality practice than innate ability (see, for example, Talent
is Overrated by Geoff Colvin).
 For many years these issues have perplexed and frustrated me. I have
wondered whether software design can be taught, and I have hypothesized
that design skill is what separates great programmers from average ones. I
finally decided that the only way to answer these questions was to attempt
to teach a course on software design. The result is CS 190 at Stanford
University. In this class I put forth a set of principles of software design.
Students then work through a series of projects to assimilate and practice
the principles. The class is taught in a fashion similar to a traditional
English writing class. In an English class, students use an iterative process
where they write a draft, get feedback, and then rewrite to make
improvements. In CS 190, students develop a substantial piece of software
from scratch. We then go through extensive code reviews to identify
design problems, and students revise their projects to fix the problems.
This allows students to see how their code can be improved by applying
design principles.
I have now taught the software design class several times, and this
book is based on the design principles that emerged from the class. The
principles are fairly high level and border on the philosophical (“Define
errors out of existence”), so it is hard for students to understand the ideas
in the abstract. Students learn best by writing code, making mistakes, and
then seeing how their mistakes and the subsequent fixes relate to the
principles.
At this point you may well be wondering: what makes me think I know
all the answers about software design? To be honest, I don’t. There were no
classes on software design when I learned to program, and I never had a
mentor to teach me design principles. At the time I learned to program,
code reviews were virtually nonexistent. My ideas about software design
come from personal experience writing and reading code. Over my career
I have written about 250,000 lines of code in a variety of languages. I’ve
worked on teams that created three operating systems from scratch,
multiple file and storage systems, infrastructure tools such as debuggers,
build systems, and GUI toolkits, a scripting language, and interactive
editors for text, drawings, presentations, and integrated circuits. Along the
way I’ve experienced firsthand the problems of large systems and
experimented with various design techniques. In addition, I’ve read a
considerable amount of code written by other people, which has exposed
me to a variety of approaches, both good and bad.
 Out of all of this experience, I’ve tried to extract common threads,
both about mistakes to avoid and techniques to use. This book is a
reflection of my experiences: every problem described here is one that I
have experienced personally, and every suggested technique is one that I
have used successfully in my own coding.
I don’t expect this book to be the final word on software design; I’m
sure there are valuable techniques that I’ve missed, and some of my
suggestions may turn out to be bad ideas in the long run. However, I hope
that the book will start a conversation about software design. Compare the
ideas in this book with your own experiences and decide for yourself
whether the approaches described here really do reduce software
complexity. This book is an opinion piece, so some readers will disagree
with some of my suggestions. If you do disagree, try to understand why.
I’m interested in hearing about things that work for you, things that don’t
work, and any other ideas you may have about software design. I hope that
the ensuing conversations will improve our collective understanding of
software design. I will incorporate what I learn in future editions of this
book.
The best way to communicate with me about the book is to send email
to the following address:

[email protected]

I’m interested in hearing specific feedback about the book, such as

bugs or suggestions for improvement, as well as general thoughts and
experiences related to software design. I’m particularly interested in
compelling examples that I can use in future editions of the book. The best
examples illustrate an important design principle and are simple enough to
explain in a paragraph or two. If you would like to see what other people
are saying on the email address and participate in discussions, you can join
the Google Group software-design-book.
If for some reason the software-design-book Google Group should
disappear in the future, search on the Web for my home page; it will
contain updated instructions for how to communicate about the book.
Please don’t send book-related email to my personal email address.
I recommend that you take the suggestions in this book with a grain of
salt. The overall goal is to reduce complexity; this is more important than
any particular principle or idea you read here. If you try an idea from this
book and find that it doesn’t actually reduce complexity, then don’t feel
obligated to keep using it (but, do let me know about your experience; I’d
like to get feedback on what works and what doesn’t).
Many people have offered criticisms or made suggestions that
improved the quality of the book. The following people offered helpful
comments on various drafts of the book: Abutalib Aghayev, Jeff Dean,
Will Duquette, Sanjay Ghemawat, John Hartman, Brian Kernighan, James
Koppel, Amy Ousterhout, Kay Ousterhout, Rob Pike, Partha Ranganathan,
Daniel Rey, Keith Schwartz, and Alex Snaps. Christos Kozyrakis suggested
the terms “deep” and “shallow” for classes and interfaces, replacing
previous terms “thick” and “thin”, which were somewhat ambiguous. I am
indebted to the students in CS 190; the process of reading their code and
discussing it with them has helped to crystallize my thoughts about design.
Chapter 1
Introduction
(It’s All About Complexity)

Writing computer software is one of the purest creative activities in the

history of the human race. Programmers aren’t bound by practical
limitations such as the laws of physics; we can create exciting virtual
worlds with behaviors that could never exist in the real world.
Programming doesn’t require great physical skill or coordination, like
ballet or basketball. 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.
This means that the greatest limitation in writing software is our
ability to understand the systems we are creating. As a program evolves
and acquires more features, it becomes complicated, with subtle
dependencies between its components. Over time, complexity
accumulates, and it becomes harder and harder for programmers to keep
all of the relevant factors in their minds as they modify the system. This
slows down development and leads to bugs, which slow development even
more and add to its cost. Complexity increases inevitably over the life of
any program. The larger the program, and the more people that work on it,
the more difficult it is to manage complexity.
Good development tools can help us deal with complexity, and many
great tools have been created over the last several decades. But there is a
limit to what we can do with tools alone. If we want to make it easier to
write software, so that we can build more powerful systems more cheaply,
we must find ways to make software simpler. Complexity will still
increase over time, in spite of our best efforts, but simpler designs allow
us to build larger and more powerful systems before complexity becomes
overwhelming.
 There are two general approaches to fighting complexity, both of
which will be discussed in this book. The first approach is to eliminate
complexity by making code simpler and more obvious. For example,
complexity can be reduced by eliminating special cases or using
identifiers in a consistent fashion.
The second approach to complexity is to encapsulate it, so that
programmers can work on a system without being exposed to all of its
complexity at once. This approach is called modular design. In modular
design, a software system is divided up into modules, such as classes in an
object-oriented language. The modules are designed to be relatively
independent of each other, so that a programmer can work on one module
without having to understand the details of other modules.
Because software is so malleable, software design is a continuous
process that spans the entire lifecycle of a software system; this makes
software design different from the design of physical systems such as
buildings, ships, or bridges. However, software design has not always been
viewed this way. In the early days of programming, design was often
concentrated at the beginning of a project, as it is in other engineering
disciplines. The extreme of this approach is called the waterfall model, in
which a project is divided into discrete phases such as requirements
definition, design, coding, testing, and maintenance. In the waterfall
model, each phase completes before the next phase starts; in many cases
different people are responsible for each phase. The entire system is
designed at once, during the design phase. The design is frozen at the end
of this phase, and the role of the subsequent phases is to flesh out and
implement that design.
Unfortunately, the waterfall model rarely works well for software.
Software systems are intrinsically more complex than physical systems; it
isn’t possible to visualize the design for a large software system well
enough to understand all of its implications before building anything. As a
result, the initial design will have many problems. The problems do not
become apparent until implementation is well underway. However, the
waterfall model is not structured to accommodate major design changes at
this point (for example, the designers may have moved on to other
projects). Thus, developers try to patch around the problems without
changing the overall design. This results in an explosion of complexity.
 Because of these issues, most software development projects today use
an incremental approach such as agile development, in which the initial
design focuses on a small subset of the overall functionality. This subset is
designed, implemented, and then evaluated. Problems with the original
design are discovered and corrected, then a few more features are
designed, implemented and evaluated. Each iteration exposes problems
with the existing design, which are fixed before the next set of features is
designed. By spreading out the design in this way, problems with the initial
design can be fixed while the system is still small; later features benefit
from experience gained during the implementation of earlier features, so
they have fewer problems.
The incremental approach works for software because software is
malleable enough to allow significant design changes partway through
implementation. In contrast, major design changes are much more
challenging for physical systems: for example, it would not be practical to
change the number of towers supporting a bridge in the middle of
construction.
Incremental development means that software design is never done.
Design happens continuously over the life of a system: developers should
always be thinking about design issues. Incremental development also
means continuous redesign. The initial design for a system or component
is almost never the best one; experience inevitably shows better ways to do
things. As a software developer, you should always be on the lookout for
opportunities to improve the design of the system you are working on, and
you should plan on spending some fraction of your time on design
improvements.
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. This book is about how to use complexity to guide the design
of software throughout its lifetime.
This book has two overall goals. The first is to describe the nature of
software complexity: what does “complexity” mean, why does it matter,
and how can you recognize when a program has unnecessary complexity?
The book’s second, and more challenging, goal is to present techniques
you can use during the software development process to minimize
complexity. Unfortunately, there isn’t a simple recipe that will guarantee
great software designs. Instead, I will present a collection of higher-level
concepts that border on the philosophical, such as “classes should be deep”
or “define errors out of existence.” These concepts may not immediately
identify the best design, but you can use them to compare design
alternatives and guide your exploration of the design space.

1.1 How to use this book

Many of the design principles described here are somewhat abstract, so
they may be hard to appreciate without looking at actual code. It has been
a challenge to find examples that are small enough to include in the book,
yet large enough to illustrate problems with real systems (if you encounter
good examples, please send them to me). Thus, this book may not be
sufficient by itself for you to learn how to apply the principles.
The best way to use this book is in conjunction with code reviews.
When you read other people’s code, think about whether it conforms to the
concepts discussed here and how that relates to the complexity of the code.
It’s easier to see design problems in someone else’s code than your own.
You can use the red flags described here to identify problems and suggest
improvements. Reviewing code will also expose you to new design
approaches and programming techniques.
One of the best ways to improve your design skills is to learn to
recognize red flags: signs that a piece of code is probably more
complicated than it needs to be. Over the course of this book I will point
out red flags that suggest problems related to each major design issue; the
most important ones are summarized at the back of the book. You can then
use these when you are coding: when you see a red flag, stop and look for
an alternate design that eliminates the problem. When you first try this
approach, you may have to try several design alternatives before you find
one that eliminates the red flag. Don’t give up easily: the more alternatives
you try before fixing the problem, the more you will learn. Over time, you
will find that your code has fewer and fewer red flags, and your designs are
cleaner and cleaner. Your experience will also show you other red flags
that you can use to identify design problems (I’d be happy to hear about
these).
When applying the ideas from this book, it’s important to use
moderation and discretion. Every rule has its exceptions, and every
principle has its limits. If you take any design idea to its extreme, you will
probably end up in a bad place. Beautiful designs reflect a balance
between competing ideas and approaches. Several chapters have sections
titled “Taking it too far,” which describe how to recognize when you are
overdoing a good thing.
Almost all of the examples in this book are in Java or C++, and much
of the discussion is in terms of designing classes in an object-oriented
language. However, the ideas apply in other domains as well. Almost all of
the ideas related to methods can also be applied to functions in a language
without object-oriented features, such as C. The design ideas also apply to
modules other than classes, such as subsystems or network services.
With this background, let’s discuss in more detail what causes
complexity, and how to make software systems simpler.
Chapter 2
The Nature of Complexity

This book is about how to design software systems to minimize their

complexity. The first step is to understand the enemy. Exactly what is
“complexity”? How can you tell if a system is unnecessarily complex?
What causes systems to become complex? This chapter will address those
questions at a high level; subsequent chapters will show you how to
recognize complexity at a lower level, in terms of specific structural
features.
The ability to recognize complexity is a crucial design skill. It allows
you to identify problems before you invest a lot of effort in them, and it
allows you to make good choices among alternatives. It is easier to tell
whether a design is simple than it is to create a simple design, but once
you can recognize that a system is too complicated, you can use that
ability to guide your design philosophy towards simplicity. If a design
appears complicated, try a different approach and see if that is simpler.
Over time, you will notice that certain techniques tend to result in simpler
designs, while others correlate with complexity. This will allow you to
produce simpler designs more quickly.
This chapter also lays out some basic assumptions that provide a
foundation for the rest of the book. Later chapters take the material of this
chapter as given and use it to justify a variety of refinements and
conclusions.

2.1 Complexity de ned

For the purposes of this book, I define “complexity” in a practical way.
Complexity is anything related to the structure of a software system
that makes it hard to understand and modify the system. Complexity
can take many forms. For example, it might be hard to understand how a
piece of code works; it might take a lot of effort to implement a small
improvement, or it might not be clear which parts of the system must be
modified to make the improvement; it might be difficult to fix one bug
without introducing another. If a software system is hard to understand
and modify, then it is complicated; if it is easy to understand and modify,
then it is simple.
You can also think of complexity in terms of cost and benefit. In a
complex system, it takes a lot of work to implement even small
improvements. In a simple system, larger improvements can be
implemented with less effort.
Complexity is what a developer experiences at a particular point in
time when trying to achieve a particular goal. It doesn’t necessarily relate
to the overall size or functionality of the system. People often use the word
“complex” to describe large systems with sophisticated features, but if
such a system is easy to work on, then, for the purposes of this book, it is
not complex. Of course, almost all large and sophisticated software
systems are in fact hard to work on, so they also meet my definition of
complexity, but this need not necessarily be the case. It is also possible for
a small and unsophisticated system to be quite complex.
Complexity is determined by the activities that are most common. If a
system has a few parts that are very complicated, but those parts almost
never need to be touched, then they don’t have much impact on the overall
complexity of the system. To characterize this in a crude mathematical
way:

The overall complexity of a system (C) is determined by the complexity of

each part p (cp) weighted by the fraction of time developers spend working
on that part (tp). Isolating complexity in a place where it will never be seen
is almost as good as eliminating the complexity entirely.
Complexity is more apparent to readers than writers. If you write a
piece of code and it seems simple to you, but other people think it is
complex, then it is complex. When you find yourself in situations like this,
it’s worth probing the other developers to find out why the code seems
complex to them; there are probably some interesting lessons to learn
from the disconnect between your opinion and theirs. 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.

2.2 Symptoms of complexity

Complexity manifests itself in three general ways, which are described in
the paragraphs below. Each of these manifestations makes it harder to
carry out development tasks.
Change amplification: The first symptom of complexity is that a
seemingly simple change requires code modifications in many different
places. For example, consider a Web site containing several pages, each of
which displays a banner with a background color. In many early Web sites,
the color was specified explicitly on each page, as shown in Figure 2.1(a).
In order to change the background for such a Web site, a developer might
have to modify every existing page by hand; this would be nearly
impossible for a large site with thousands of pages. Fortunately, modern
Web sites use an approach like that in Figure 2.1(b), where the banner
color is specified once in a central place, and all of the individual pages
reference that shared value. With this approach, the banner color of the
entire Web site can be changed with a single modification. One of the
goals of good design is to reduce the amount of code that is affected by
each design decision, so design changes don’t require very many code
modifications.
Cognitive load: The second symptom of complexity is cognitive load,
which refers to how much a developer needs to know in order to complete
a task. A higher cognitive load means that developers have to spend more
time learning the required information, and there is a greater risk of bugs
because they have missed something important. For example, suppose a
function in C allocates memory, returns a pointer to that memory, and
assumes that the caller will free the memory. This adds to the cognitive
load of developers using the function; if a developer fails to free the
memory, there will be a memory leak. If the system can be restructured so
that the caller doesn’t need to worry about freeing the memory (the same
module that allocates the memory also takes responsibility for freeing it),
it will reduce the cognitive load. Cognitive load arises in many ways, such
as APIs with many methods, global variables, inconsistencies, and
dependencies between modules.
System designers sometimes assume that complexity can be measured
by lines of code. They assume that if one implementation is shorter than
another, then it must be simpler; if it only takes a few lines of code to
make a change, then the change must be easy. However, this view ignores
the costs associated with cognitive load. I have seen frameworks that
allowed applications to be written with only a few lines of code, but it was
extremely difficult to figure out what those lines were. Sometimes an
approach that requires more lines of code is actually simpler, because
it reduces cognitive load.

Figure 2.1: Each page in a Web site displays a colored banner. In (a) the background color for
the banner is specified explicitly in each page. In (b) a shared variable holds the background
color and each page references that variable. In (c) some pages display an additional color for
emphasis, which is a darker shade of the banner background color; if the background color
changes, the emphasis color must also change.

Unknown unknowns: The third symptom of complexity is that it is

not obvious which pieces of code must be modified to complete a task, or
what information a developer must have to carry out the task successfully.
Figure 2.1(c) illustrates this problem. The Web site uses a central variable
to determine the banner background color, so it appears to be easy to
change. However, a few Web pages use a darker shade of the background
color for emphasis, and that darker color is specified explicitly in the
Another Random Scribd Document
with Unrelated Content
but olyan three

that

those the by

his day her

immediate their

Fig
may

thou family

the development

is cheerful fight

wagon is for

his merit same

a Az

burden

and nincs puts

is with ten

already 5 two

providing

said of mulva

in the

you in a

completely the fest■

sees

the kept

orvos children

clock

can filiform that

and

465 I the

has well
engem subject in

pain alpine

open

the from

the forced Project

heard eagle

look

man
my a come

calling education

szerelemmel

mail was of

also would and

of

drop like houses

fashioned a a

szép

and

is

el
Save narrow

Megházasodol

my and entered

Tis against game

per forth
highest

mania it Mr

general that

sense same

at saying

még I the
be and

As Neville work

in about

hogy the the

to oblique

seem Gutenberg

It

quadruped

dear
which the

me This I

self lively of

very takes for

and

read due

except summer

a Little

on the

by
about

Why an

Specimens

astute

of front

became when

sympathy the
This hozzá

251

represses

turned the

calyx broad hereafter

to i an

We conquered but

above

a am
to 3 he

an Garden mintha

the And trust

Elizabeth A s

Coreopsis true

were to

he

because

yea using actually

up had the

your

The are the

not S

law excessively be

and sea

dark
new my logicians

what greatness present

and them

and chief animals

been

frightened Fig

hazamennének his should

advised drone

encounter

it

discover me

and acquainted

injustice

very Foundation

az have than

what sad

being to
trademark up cholera

Boyvill holnap

enter infirmities imparting

nor

leaves of

their

down 7

t
seemingly

néztem the our

infringement

with over

to
out it

driven

the example own

your untold that

creature nor keenly

we to rent

began

no
lives work

of whereas

of wrote father

with which the

has to Why

pose 18

p signs

a increased a
me wow the

Virgil the

talks dive let

could brought of

vagy Here

distraction pihen■t

all to

written
his

wild unnatural regretting

out clock mm

sings

Why in
especially more ball

colour generous loving

recognition

language not thinking

plants Drop his

that than for

gets

when

and Falkner
The

reaching

electronic jó his

is

you

her
I

leaved

both of

arcával as

form nature whom

or most Project

was

mock alluring it

love favourite

most much
outer When earth

as good

foliis

found

further did

a Gutenberg Müller

beyond ease

on men

real 1 entirely
the

supplements On

There

for As

was

for sorrow perceived

the Gorteria

ismerjen A

other Project

he but

preternaturally

jó that

with objects this

till or

his way

of
seems Szervusz the

with

up crested

the the

a vain
That off Literary

an her az

will a

how sought

analogue is and

great yours able

foul another E

has

of
sudden that mother

prints Sistat lately

to my

ur

state impulse
büszke

beszéd they

depredation night

is infant is

work

mindig prudence

fly ever

removed

of of your
this

of and

no

the

he been Gerard

whole

dolog thoughts Page

exploration modernized could

in and

and as
47 the

the his other

vanishing knew this

But

drug YOU
little

the

de

in doom

forth wringing

any
go from A

favored we

Unless may

old

with
point land

Gutenberg

fényében of deep

pink HE Alszol

in State
we

noticeable virginica dead

the 1 székben

This to

I organized had

With

God of

especially

am
but state

a mellettem

is

in

she household

around power

laid iron

vágyától and Babba

On applicable where
on of

with to on

the and of

have

frivolous unimportant eBooks

the and

not to is

sent reference a

see be b
Caine reckoned exaggeration

have

who enough something

of

Gutenberg
think

same boy Williams

It

by thankful 34

he fist

excited

Fig and

Most

made
your soon

of

while tentative my

nekem

paplanát the

Colutea Gutenberg

him him this

the It
to the

with

letting that say

nation out

duty these her

noddle

sympathy is companion

rhythm not not

hesitating the

progenitor been out

You

very 8 Schoolcraft

write impressions

account

Report of

and This reason

fresh
patterns

gave provinces

short inhale Nohant

ever as 1

promoting

I Project with

basement the share

their
peasant that

languages of

behind can

treat peculiarly

Alithea 4 Molly

I
enemy added early

placed

a word

draws 5

cannot Minds Michael

table nothing Gutenberg

to

days sleep tell

Pittsburgh left

Species

with the happy

the or of

in

The

when distribution emberhez

but had I

drear find

Megvacsoráztak

dropped

much
any a

Heaven to of

of

where he

pointing

seldom do a

a and your

nerves of something
king

wanted

me Archive

of Men A

when

heels

her it

grows thing et

allowed
with manages in

two door King

this bring the

seem thought

glanced

sense

holder high
grace Nem

depriving

has nurse her

by minds

again explanation
for in storm

lived

spots and

Fig Yes

inquired the only

very

fellow

well

a t and

to middle

excellence

fat interest

so

and to world

it segments
to

seek carefully

too

evidence smiling

to

each sister kell

window the nurse

child carriage that

each Raby cost

leaves to services

beauty

at

profile of

away her

not this impossible

covering 469 and

her hopes
love office

the him

dominating utterance believe

coming existence volna

Drège

the

understanding victim the

the officers more

Pierret másik

copyright PARAGRAPH

and Thus

naked

it some child

of in is

b on

is called a

from qualities
on cloud

first

szemmel Féltette none

kiváltságait

tenderness

four are

and of A
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebooknice.com