1.5.

2 General principles
The dictionary defines the word principle as “an important law or assumption underlying and required by a
system of thought.” This book will discuss principles at many different levels of abstraction. Some focus on
software engineering as a whole, others consider a specific general structural activity (e.g.,
communication), and still others focus on software engineering actions (e.g., architecture design) or
technical tasks (writing a scenario for use). No matter your level of focus, the principles will help you
establish a mental toolkit for solid software engineering practice. That's why they're important.
David Hooker [Hoo96] proposed seven principles that focus on the practice of software engineering as a
whole. They are reproduced in the following paragraphs:13
First Principle: The Reason Everything Exists
A software system exists for one reason: to provide value to its users. All decisions must be made with
Before starting a software
this in mind. Before you specify a system requirement, before you note the functionality of a part of a system,
project, make sure the
software has a business
before you determine hardware platforms or develop processes, ask yourself questions such as: “Does this
purpose and that users add real value to the system?” If the answer is “no,” then don’t do it. All other principles support this one.
perceive value in it. Second principle: MSE (Keep it simple, stupid…)
Software design is not a capricious process. There are many factors to consider in any design activity.
Every design should be as simple as possible, but no simpler.

13 Reproduced with permission of the author [Hoo96]. Hooker defines some patterns for these principles at http://c2.com/cgi/wiki?
SevenPrinciplesOfSoftwareDevelopment.
 This makes it easier to achieve a system that is more easily understood and maintainable, but that does not
mean that features or even internal traits should be discarded in the name of simplicity. In fact, the most
APPOINTMENT:
elegant designs are usually the simplest. Simple doesn't mean “quick and dirty” either. The truth is that it
“There is a certain majesty
often takes a lot of thought and work with multiple iterations to simplify. The reward is software that is easier
in simplicity, which is by
far all that adorns wit.” to maintain and less prone to error.
Third principle: Maintain the vision
Pope Alexander (1688-
1744) A clear vision is essential for the success of a software project. Without it, the project will almost infallibly
end up being a being “with two [or more minds].” Without conceptual integrity, a system is in danger of
becoming a maze of incompatible designs held together by the wrong kinds of screws […] Compromising the
architectural vision of a software system weakens and will eventually cause the collapse of even well-
designed systems. Having an architect who can maintain the vision and enforce it ensures a very successful
software project.
Fourth principle: Others will consume what you produce
An industrial-strength software system is rarely built in a vacuum. In one way or another, someone else
will use it, maintain it, document it, or otherwise depend on your ability to understand the system. So always
CLUE specify, design and implement with the confidence that someone else will have to understand what you do.
If software has value, it will
The audience for any software development product is potentially large. Develop specifications with users in
change over its lifetime.
For this reason, it must be
mind. Design with implementers in mind. Code with those who need to maintain and expand the system in
built in a way that is easy mind. Someone has to debug the code you write, and that makes them a user of your code. Making your job
to maintain. easier adds value to the system.
Fifth principle: Open yourself to the future
A system with a long life span has more value. In today's computing environments, where specifications
change at a moment's notice and hardware platforms become obsolete after just a few months, it is common
for software lifespan to be measured in months rather than years. However, truly “industrial-strength”
software systems must last much longer. To be successful at this, systems must be easy to adapt to these
and other changes. The systems that achieve this are those that were designed to do so from the beginning.
Never design on something that has already been started. Always ask, “what if…?” and prepare for all
possible answers by creating systems that solve the general problem, not just a specific one.14 This will likely
lead to reusing an entire system.
Sixth principle: Plan ahead for reuse
Reusing saves time and effort.15 When developing a software system, achieving a high level of reuse is
perhaps the most difficult goal to achieve. Code and design reuse has been recognized as one of the
greatest benefits of using object-oriented technologies. However, the recovery of this investment is not
automatic. To enhance the reuse possibilities that object-oriented [or conventional] programming provides,
reflection and planning are required. There are many techniques for incorporating reuse into each level of the
system development process… Planning ahead for reuse decreases the cost and increases the value of
both the reusable components and the systems in which they are incorporated.
Seventh principle: Think!
This last principle is perhaps the most overlooked. Thinking things through clearly before taking action
almost always produces better results. When you think about something, you are more likely to do it well.
Likewise, knowledge is also gained by thinking about how to do it right again. If you think about something
and still do it wrong, that becomes a valuable experience. A side effect of thinking is learning to recognize
when you don't know something, at which point you can research the answer. When clear thoughts have
been put into a system, value manifests itself. Applying the first six principles requires hard thinking, so the
potential rewards are enormous.
14 It is dangerous to take this advice to extremes. Designing to solve “the general problem” sometimes requires performance
compromises and can make specific solutions inefficient.
15 While this is true for those who reuse software in future projects, reuse can be expensive for those who must design and build
reusable components. Studies indicate that designing and building reusable components can cost between 25 and 200% more
than the software itself. In certain cases the difference in costs is not justified.
If every engineer and software team would just follow Hooker's seven principles, many of the difficulties
experienced when building complex computer-based systems would be eliminated.