Standing on Principle
Karl E. Wiegers
Copyright © 1997 by Karl E. Wiegers
You may be asked to cut corners on the quality of the work you
do or the way you do it. Sometimes, the person making the request
is a manager who doesn't appreciate the value of the quality activities
you practice, or someone who feels budget and schedule pressures
you may not. Sometimes, it is a customer who wants you to address
only her specific needs, even though you have identified an opportunity
to generalize beyond her requirements to provide enhanced value
to a broader user community within your own company. Customers
and managers alike may press you to skip key engineering steps
from time to time. It would be nice to think we are beyond the
stage of "don't bother with those specs, start writing code,"
but this call of the software dinosaur still echoes throughout
It's not easy to resist these pressures from the people who pay
the bill or your salary. Sometimes you have no choice: Do what
is asked of you, or head out the door. But people working in a
quality-oriented software engineering culture will do their best
to follow established and intelligent practices in times of crisis,
as well as in normal times. Developers and managers must adopt
personal standards that motivate them to stick to their software
process guns in the heat of battle. You might need to temper this
idealism with the reality of keeping your job, but start from
the position of quality being paramount. Whenever a situation
arises that calls for a value judgment, an ethical decision, or
a choice between doing what is right and doing what you are asked
to do, remember this principle: Never let your boss or your customer
talk you into doing a bad job.
Perhaps it sounds like heresy, but the customer is not always
right; however, the customer always has a point. Too often, software
developers incorporate every feature requested by a customer into
a requirements specification without regard to how much effort
it will take to implement, or whether it is truly necessary to
achieve the customer's objectives. While you must respect the
attitudes and requests made by every customer, don't be blinded
by the notion that you are hearing the "voice of the customer"
and therefore must do whatever that voice says. Much of the value
that a systems analyst adds to the application development process
comes from looking for solutions that address the true user needs
with creativity, efficiency, and thoughtfulness.
Some years ago, our software group at Kodak developed a PC-based
system for controlling some lab equipment. The customers asked
us to write a pop-up calculator program the users could invoke
while they were running the program (this was before the advent
of windowing systems that made such features commonplace). After
a little thought, we concluded it would be cheaper simply to buy
a basic calculator for each of the hundred-odd anticipated users
and slap one on the side of each monitor with a piece of Velcro®.
The customer need was for a calculator function-it didn't really
have to be built into the software. That was just a cute, but
unnecessarily expensive, solution the customer envisioned. There
are two lessons here:
Look past the customer's request for a feature to find the
underlying real need; and, look for simple and cheap solutions
for the real need, not just the solution that the customer initially
requested or one that looks neat.
Everyone is subject to tunnel vision. Customers think in terms
of what functions they personally will use in the application,
not those that should be included because of their potential value
to other users. We ran into this situation on another project,
which was requested by one area of the research laboratories at
Kodak. Not surprisingly, the primary customer representative focused
on the needs of the community she represented. However, the analyst
spotted several places where the application could be made more
generally useful without a lot of extra effort, thereby meeting
the needs of other research departments.
This customer rep was reluctant to have us spend the extra time
building in these generalizations. However, we felt they would
enable Kodak to leverage the investment in this custom software
over a broader internal user community. So, we went ahead and
designed the system to incorporate these generalizations. In this
case, we were willing to incur the unhappiness of the primary
customer, because we were doing the right thing for the company.
If her department had declined to pay for the extra work required
for the more general solution, we would have funded it in some
other appropriate way. The lesson here is
Look beyond the local interests of the primary customers to
see whether you can easily generalize an application to meet a
This rationale also applies to the identification of potentially
reusable components in the course of application design. It will
always take more time to design, implement, and verify a reusable
component than to code a custom solution for one project. Think
of designing for reuse as an investment you can cash in on multiple
future projects, for the good of the company. Don't let resistance
by your customer or your manager inhibit you from making smart
Occasionally, you may encounter a customer who is a self-styled
software engineer and who therefore wishes to provide a lot of
technical input into how you design his application. This is usually
a case of someone having just enough knowledge to be dangerous.
The project leader must resist letting such customers become technically
involved in design and implementation (unless, of course, the
customer really does know what he's doing). Focus his energy
on the requirements, or get him involved with testing and writing
user aids, but do not let the customer drive the technical aspects
of the project. The rule to remember is
Make sure you know where the customer's software expertise
stops. Do not allow the customer to intimidate you into making
poor design decisions.
Developers must base their relationships with customers on mutual
trust and respect. We expect our customers to be forthright with
us about their requirements and constraints, and they expect us
to be straight with them on cost and schedule. Conversely, when
customers come to developers with changes in the established requirements
baseline, we have to make sure they understand the impact of the
changes they are requesting. New or modified requirements may
not look so attractive once the customers know the cost, in terms
of dollars or delivery time, of a late change. By the same token,
if schedules slip as the project progresses, the customers have
to be kept informed, even if they don't want to hear it.
I know of one developer who had originally promised to deliver
a new application in October. He fell behind on the project, and
as of September, it was clear that several months of work remained
to be done. Unfortunately, the developer had not updated his delivery
estimate with the customers: They still expected the system to
be ready in October. We had to do some quick expectation management.
As you might expect, the customers weren't happy about the "sudden"
change in schedule. This developer didn't think about this principle:
Be honest with your customers. The project stakeholders are
entitled to accurate information, whether or not it is good news.
Do you ever say you will do something and then never get around
to it? I feel this reflects a lack of personal integrity. Follow
through on the commitments you have made. However, if something
changes-you decided you won't do it, or you are unable to do it
on time for whatever reason-talk about it! There are many reasons,
some good and others not so good, why you might not be able to
fulfill a commitment, but it is irresponsible not to notify those
affected by your decision. So long as you are open about a problem,
you can work out a solution. The message is this:
If you agree to a commitment, the other people involved expect
you to do it. If anything changes, let them know as soon as you
can, so you can work out an alternative.
As a manager, I told my team members it was their right and their
responsibility to tell me when their backlog pile became too high.
Then it was my responsibility to help them deal with the
pile. When I asked them to take on a new task, it was completely
acceptable for them to reply, "Sure, I can do that, Karl.
What would you like me to stop doing to free up the necessary
time?" Until they told me the pile was too high, I had no
way of knowing that this was the case. Naomi Karten suggests reasons
and ways to "just say whoa" .
A colleague was once asked by a manager to estimate the delivery
time for a planned large software application. He replied, "Two
years." The manager said, "No, that's too long. How
about six months?" My colleague's response was, "Okay."
Wrong answer! What changed in the five seconds that elapsed between
his first estimate of two years, and his second statement, agreeing
to a schedule only one-quarter as long? Nothing, except that he
thought the manager wanted to believe that six months was feasible.
The project did not suddenly shrink by 75 percent, nor did the
available staff increase four-fold or instantly become four times
as productive. The project was not reestimated based on an improved
algorithm. My colleague simply said what the manager wanted to
hear, undermining his own credibility as a software estimator
and project leader. To no one's surprise, the project extended
beyond two years. Agreeing to unattainable commitments is unprofessional
and unfair to all involved, including yourself.
How should this all-too-common situation have been handled? Here
are a few approaches to try; there is no guarantee that any of
them will work with unreasonable managers or customers, but try
them first before caving in.
- Explain your estimating method to the manager, and ask on
what basis the manager's estimate is smaller. The manager may
not really have an estimate, but he has a goal. You may not have
an estimate, either, only a guess. It's harder to argue with an
estimate based on some analytical, quantitative process than with
a number pulled out of thin air. Historical metrics data can help
build your case.
- If you can't provide an accurate estimate because there are
no written requirements, offer to provide a more precise estimate
after some initial exploration of the project scope and general
- Point out that an estimate made very early in a project can
be off by 80 percent or more. Present a range of estimates: best
case, most likely, and worst case, with the approximate probability
of meeting each one. Presenting a single estimate at the beginning
of a sizable project sets an expectation that will persist in
people's minds long after the original requirements and assumptions
have drastically changed.
- Negotiate for a larger team, fewer features, phased delivery,
or reduced quality as ways to achieve an aggressively accelerated
schedule. Make sure the stakeholders understand these trade-offs:
They will not get something for nothing.
- Redo your estimate with some different assumptions of project
size, resources, or other factors, to see how close you can come
to the manager's shorter goal. Make sure the assumptions are clearly
communicated to everyone involved in the decision-making.
- Make a counteroffer, showing the manager what fraction of
the system's functionality realistically could be delivered in
Concealing a project's scope from management is even more irresponsible
than agreeing to a schedule you cannot possibly meet. One project
leader was leading a long-term reengineering effort, but she never
prepared a detailed project plan. She was afraid if her manager
found out how extensive (and expensive) the project really was,
the manager would squelch it. Both this project leader and her
manager acted inappropriately. The project leader should have
been forthright about defining the scope of the project and managing
it properly, while the manager should have insisted on seeing
a project plan and having some accountability. One purpose of
project planning is to identify all the tasks that have to be
performed to make the project a success. Pretending those tasks
aren't there doesn't make them go away.
There are five dimensions that must be managed on a software project:
features, quality, cost, schedule, and staff (shown in Fig. 1).
These dimensions are not all independent. For example, if you
add staff, the schedule may be shortened (although not necessarily),
and the cost may increase. A more common trade-off is to shorten
the schedule or add features, and sacrifice quality. The trade-offs
among these five dimensions are not simple or linear. For each
project, we need to decide which dimensions are critical and how
to balance the others so we can achieve the key project objectives.
Each of these five dimensions can take one of three roles on any
given project: a driver, a constraint, or a degree
of freedom. A driver is a key objective of the project. For
a product that must ship on time to meet a marketing window of
opportunity, schedule is a driver. Commercial desktop software,
such as word processors and spreadsheets, are often created with
features as the driver.
Figure 1. The five dimensions of a software project.
A constraint is a limiting factor that is not within the project
leader's control. If a team of immutably fixed size is assigned
to a project, staff becomes a constraint. Cost is a constraint
on a project being done under a fixed-price contract, while quality
will be a constraint for a project to develop software that runs
a piece of medical equipment or an airplane's flight control system.
Sometimes, you can regard cost as either a constraint or a driver,
since it could be both a primary objective and a limiting factor.
Similarly, a specified feature set may be the primary driver of
the project, but you could view it as a constraint if the feature
set is not negotiable.
Any project dimension that is neither a driver nor a constraint
becomes a degree of freedom. These are factors that the project
leader can adjust and balance to some extent, to achieve the overall
project objectives. For example, on some internal information
system projects, the drivers are features and quality, and staff
is a constraint, so the degrees of freedom become schedule and
cost. The implication for this profile is that the features demanded
by the customers will all be included, but the delivery time for
the product may be later than desirable.
An important aspect of this model is not which of the five dimensions
turn out to be drivers or constraints on any given project, but
that the relative priorities of the dimensions be negotiated in
advance by the project team, the customers, and management. All
five cannot be drivers, and all five cannot be constraints. This
negotiation process helps to define the rules and bounds of the
project. As in most games, we can play according to any set of
rules, but all of the players must understand and agree to the
rules that are in effect at any particular time.
A way to classify each dimension into one of the three categories
is to think of the amount of flexibility the project leader has
with respect to that dimension. A constraint gives the project
leader virtually no flexibility, a driver has low flexibility,
and a degree of freedom provides a wider latitude to balance that
dimension against the other four. A graphical way to depict this
is to use a Kiviat diagram, which allows us to plot several values
(five, in this case) as an irregularly shaped polygon on a set
of normalized axes. The position of each point on its axis indicates
the relative degree of flexibility of that dimension for a particular
project, on an arbitrary scale of zero (completely constrained)
to ten (complete flexibility).
Figure 2 illustrates a flexibility Kiviat diagram for one of our
group's recent applications. This project was constrained to a
fixed staff size, so the value plotted on the staff axis is zero.
The project was driven to meet a desired schedule, so the point
on the schedule axis also has a low value. The project had varying
amounts of flexibility around the features that would be incorporated
into the initial release, the product quality, and the latitude
for cost overruns. Therefore, the values for these degrees of
freedom are higher on their axes. As another example, Fig. 3 illustrates
a flexibility diagram for a hypothetical project for which quality
is a driver and the schedule shows the greatest latitude.
Figure 2. Flexibility diagram for an internal information system.
Figure 3. Flexibility diagram for a quality-driven application.
The shapes of the polygons in these examples provide a visual
indication of the important aspects of each project. If you push
the point on one of the axes inward to reduce the amount of latitude
the project leader has in that dimension, you'll generally have
to adjust the other dimensions to compensate: Nothing comes without
a price. You can apply this sort of analysis to make management
aware of the trade-offs and decisions they must make to meet a
project's key objectives, and to negotiate realistically achievable
commitments on each project. Be sure to document the negotiated
goals for driver dimensions, the limits for constraint dimensions,
and the range of values associated with those dimensions that
are degrees of freedom.
Too often, we focus only on one driver aspect (usually features
or schedule), and we overlook the impact on the other dimensions.
This is the sort of behavior that leads to those software engineering
surprises nobody likes to hear about. Customers, managers, and
the marketing department have to accept that they cannot have
all the features they want, with no defects, delivered very quickly
and at low cost by a downsized development staff.
Another way to apply the five-dimension model is to renegotiate
when the world changes. If new requirements come along that simply
must be included in the upcoming release, ask management
what you should adjust to accommodate this request:
- Should other features be deferred?
- Can the schedule be allowed to slip? by how much?
- Can you add staff or pay for overtime to meet the new schedule?
- Or, as usual, does quality slip because sound processes and
quality control practices are neglected in the press to ship something-anything-out
The specific answer is less important than the discussion that
is triggered when project leaders and developers push back against
unexpected changes in any of these five dimensions. Customers
and managers have to understand the impact of such changes on
the other project dimensions so they can make the right decisions.
One characteristic of both a healthy software engineering culture
and a mature software development process is that project expectations
and commitments are established through negotiation. To avoid
unpleasant surprises late in a project's life cycle, the stakeholders
all have to understand and agree on their objectives and priorities.
Not everyone may be happy with the outcome of the negotiations,
but people can commit to realistic schedules and deliverables
only if all the parameters are discussed honestly. Unstated or
unrealistic goals will rarely be achieved. A group with a culture
in which people are afraid to say no or to discuss problem areas
openly will always fall short of expectations . Tools like
the flexibility diagram can facilitate these frank, and often
- Karten, Naomi. Managing Expectations. New York: Dorset
House Publishing, 1994. Karten provides suggestions for working
with "people who want more, better, faster, sooner, NOW!"
Chapter 11 provides guidance on how to say "No" so it
sounds like "Yes."
- Maguire, Steve. Debugging the Development Process.
Redmond, Wash.: Microsoft Press, 1994. In Chapter 3, Maguire describes
the importance of using goals to drive your decisions, rather
than the desire to please everyone who asks for something. He
presents several anecdotes that illustrate the importance of saying
"No," and the need to rely on one's personal integrity
when asked to do something inappropriate.
[Published in The Journal of the Quality Assurance
Institute, July 1997. Reprinted with permission from the Quality
Assurance Institute. Adapted from Creating a Software Engineering
Culture by Karl E. Wiegers (Dorset House Publishing, 1996).]