Excuses 1/99 mid-line 2/1/99 1:41 PM Page 1

to
much
n s a dd tooment.
tio p
Inspec st of develo
th e c o

We p
la
ting n to sta
r rt i
year isk mana mple
men- THE LITTLE BOOK
, ge
proc after we ment nex
ess defi t
and
trai n e OF
n th the
e st
aff. BAD EXCUSES

The project is doing fine. We

nded
estimated we would have expe
milli on by this date and our
$11.3
million.
actual expenditure is $10.937

For additional information please contact the

SOFTWARE PROGRAM MANAGERS NETWORK
(703) 521-5231 • FAX (703) 521-2603
E-MAIL: BEST@SPMN.COM
HTTP://WWW.SPMN.COM
JUNE 1998
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 3

PREFACE

This publication was prepared for the

Software Program Managers Network We have all heard excuses for not doing what really
4600 North Fairfax Drive, Suite 302 should be done. When essential software disciplines and
Arlington, VA 22203 practices are not implemented on large-scale projects,
complexity snowballs into chaos and cripples or kills
programs. Since the Airlie Software Council members
The ideas and findings in this publication should not be construed as have heard lots of excuses for not effecting these disciplines
an official DoD position. It is published in the interest of scientific
and practices, we thought a selective list of excuses could
and technical information exchange.
serve to spotlight when these practices are not being
employed—and stimulate dialogue about them.
If an excuse is still used to deprive the project of an
effective discipline or practice, then considerable discussion
Norm Brown
Director, Software Program Managers Network time can be saved by simply referring to the excuse’s
Software Standard Intolerable Nonsense Number, or
Copyright © 1998 by Computers & Concepts Associates Software SIN Number.

This work was created by Computers & Concepts Associates in the
performance of Space and Naval Warfare Systems Command
(SPAWAR) Contract Number N00039-94-C-0153 for the operation
of the Software Program Managers
Network (SPMN).
In the interest of improving software, we will also
provide you with other copies of this book upon request.
We welcome any additional excuses, comments, or
suggestions you have, and look forward to hearing from you
at best@spmn.com.

Norm Brown
Executive Director
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 5

INTRODUCTION

Failed software projects are usually easy enough to

analyze after the fact. You can almost always spot some
fundamental sound practice that wasn’t followed; if it had
been followed, the project would have succeeded, or at
least failed less completely. Often the good practices that
weren’t followed are basic ones that practically everyone
knows are essential. When that happens, project
management can always cite a reason why the practice
wasn’t followed—an excuse or rationalization.
To save everyone a lot of time, we have collected some
of the most common bad excuses for not using good
practices and published them in this book. The next time
you’re considering managing a project without a careful
Work Breakdown Structure (WBS), for example, or with
no risk management, you needn’t wrack your brain for an
excuse. Just consult this book.
However, this book is not meant to suggest that there
are NO valid excuses for proceeding without a given
“good” practice. Tailoring the life cycle to fit the project’s
special circumstances is at the heart of good management.
But there are good excuses and bad ones. What follows is
a list of the bad ones.

Tom DeMarco
5
Fall 1996
1
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 7
BAD EXCUSES RELATED TO RISK
MANAGEMENT
1. We have no risk.
2. Give us an hour and we’ll tell you our top ten risk
items.
3. Making risks public will kill the program.
4. The customer goes ballistic whenever he/she hears of a
potential problem.
5. We deal with problems as they arise.
6. My customer doesn't want to hear that he/she is the
source of risk.
7. Identifying risks is bad for my career.
8. This is development—why should we worry about
supportability and maintainability risks?
9. How can you predict what will happen a year from
now?
10. Our planning horizon is six months.
11. No one on the staff knows how to do risk
management.
12. We plan to start implementing risk management next
year, after we define the process and train the staff.
13. Our job is to develop software, not fill out
bureaucratic forms.
14. The commercial software industry doesn’t waste time
on risk management.
15. We don't need a separate risk management program
because we have frequent technical interchange and
Integrated Product Team (IPT) meetings.
16. If I gave a realistic assessment, no one would listen.
17. That external interface is not in our risk management
program because the interface is not our responsibility.
18. Using that tool is not a risk. The vendor’s salesman
said so.
19. That method is proven and therefore not a risk. The
speaker at the conference said so.
20. People outside the project who don’t understand the
context will invent worst-case scenarios.
21. The program is too small to do risk management.
22. Corporate management won't buy in.
23. My tech people will rebel if we identify as a risk
betting our success on an unproven new technology.
24. My tech people will rebel if we identify as a risk a lack
of skills needed to do development.
25. We have no cost or schedule risk because new
technology will enormously increase our
productivity—by five to ten times.
26. New technology we have never used before will
mitigate the risk.
27. We have to bid the lowest cost to win; we'll worry
about doing the job when we get it.
28. If we bid everything we do, we would lose the project.
It’s a delivery-order contract.
29. We can’t identify risks based on industry metrics
because our process is different.
3
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 9
BAD EXCUSES RELATED TO RISK
MANAGEMENT (cont.)
30. You have to cut corners to win the program.
31. We don’t mitigate software risk in systems engineering
trade studies for embedded systems because software is
only a component of subsystems.
32. Our methodology is Rapid Application Development
(RAD), so we have no schedule risk.
33. Our methodology is evolutionary development, so
requirements volatility is not a risk.
34. We don’t include anyone from our hands-on software
development staff in risk identification because we
have hired an outside consultant as a risk expert.
35. We don’t include anyone from our hands-on software
development staff in risk identification because our
managers are using a generic risk database to identify
risk.
36. We don’t include anyone from our hands-on software
development staff in risk identification because they
don’t have the big picture.
37. A prime contractor is not behaving like a prime if
people from a subcontractor organization participate in
risk identification.
38. There is no risk in the planned big increase in our
software staff because of the large layoffs by defense
contractors during the past few years.
BAD EXCUSES RELATED TO
FORMAL INSPECTIONS
1. We have formal reviews to find problems.
2. We do formal inspections, starting with code walk-
throughs followed by unit test.
3. How can you inspect an architecture?
4. We are using advanced software technology that is
iterative and evolutionary, so inspections are not
applicable.
5. Inspections add too much to the cost of development.
6. Our formal inspections are audits of compliance with
process by our corporate Quality Assurance (QA)
organization.
7. Our inspections are done by an Independent
Verification and Validation (IV&V) contractor who
won the contract by bidding the lowest staff costs.
8. We don't have a formal inspection program because
we have a number of IPTs.
9. This project is not big enough to need formal
inspections.
10. Formal inspections aren't done during the
Demonstration and Validation Phase.
11. We don't need formal inspections because we are
developing our software with Computer-Aided
Software Engineering (CASE) tools that automatically
generate source code.
12. If users are allowed to get involved in verifying
system/operational requirements, we will never get
closure on those requirements.
5
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 11
BAD EXCUSES RELATED TO
FORMAL INSPECTIONS (cont.)
13. Inspections threaten my people.
14. Inspections are a waste of time because requirements
will change.
15. Execution test is the most effective way to find errors.
16. Inspections are only warranted for safety-critical
systems like nuclear weapons and medical systems.
17. Formal inspections are 20-year-old technology. We
only use leading-edge technology.
18. Formal inspections are too rigid.
BAD EXCUSES RELATED TO
CONFIGURATION MANAGEMENT
(CM)
1. CM only applies to documents.
2. CM only applies to source code.
3. CM is not appropriate during development because we
are using the latest iterative and concurrent
engineering and evolutionary process models.
4. CM is not appropriate during development because
our development approach is rapid prototyping.
5. It's not that big a project.
6. You can't stop the technical people from making a
quick patch when they find a problem in integration
test or in the field.
7. We made the change without bothering to submit an
Engineering Change Proposal (ECP) because the
customer's technical manager asked us to and we want
a satisfied customer.
8. We don’t need a separate CM effort because CM is
automatically done by the Upper and Lower CASE
tools we will use.
9. It's too hard to go back to the CASE tool and change
the design, so we change the design with changes to
the source code generated by the CASE tool.
10. We have de-emphasized CM because MIL-STD-973
has been superseded by MIL-STD-498, which puts
much less emphasis on CM.
11. We don't have CM on several of our external
interfaces because they are the responsibilities of
other organizations.
7
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 13

BAD EXCUSES RELATED TO

CONFIGURATION MANAGEMENT
(cont.)

12. CM is a DoD-unique practice, and DoD now follows
commercial practices.
13. Our developers do not turn source code units over to
CM because CM does not have the technical skill
needed to build modules for integration test.
14. We don't do CM on internal interfaces because this
limits technical team flexibility.
15. Our CM staff keeps all records manually because they
are not experienced with software tools for CM.
16. CM will be minimal on this project because most of
the software will be an integration of Government-
Off-the-Shelf (GOTS) and Commercial-Off-the-Shelf
(COTS) software.
17. We lower our cost by using only minimum-wage
persons on our CM staff because CM does not require
much skill.
18. We don’t use the same CM process and tools as our
subcontractors because they have a different corporate
process.
19. We don’t need functional and physical configuration
audits because we are using CASE tools.
20. We don’t put the software architecture and detailed
design under formal change control during
development because this limits the flexibility of the
developers.
21. We don’t put operating systems, middleware, run-time
libraries, and compilers under CM because CM only
applies to the application software that is developed
under this contract.
22. We don’t put software development files under CM
because they are not contract deliverables.
23. The only baselines controlled by the buyer are the
functional, allocated, and product baselines. Therefore
the buyer has no right to see any contractor data from
the developmental baseline.
24. CM cannot control anything in the developmental
baseline other than source code because we are using
CASE tools and CM tools that are not integrated.
25. CM can only control information stored in flat files
because our CM tool only manages flat files.

9
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 15
BAD EXCUSES RELATED TO
PEOPLE
1. We don't need good people because we have good
process.
2. The only thing my technical people want is to work
on a challenging technical problem.
3. Only business types care about the symbols of success
such as offices and titles.
4. If the technical staff pulls off the delivery by working
twenty hours a week unpaid overtime for months, we
will give the project manager a big bonus.
5. We don't invest in training our technical staff because
they are too busy.
6. We don't invest in training because it costs too much.
7. If we train our technical staff, their market value will
increase and they will leave.
8. Any kind of engineer can learn to develop software in
a few months.
9. With the new software technology such as 4GL, CASE
tools, and RAD, the users can develop the software as
easily as professional software engineers.
10. That big jump in staff shown in our project plan is no
risk because we will have no problem quickly hiring a
large number of software engineers to design databases
and client/server network applications.
11. There is no shortage of skilled software developers in
the U.S. Haven’t you heard about the massive layoffs
in the defense industry?
12. We can't hire the needed lead software design engineer
because he/she demands a salary higher than the labor
rates we bid to win the project.
13. We can't hire the needed lead software design engineer
because he/she demands a salary higher than our
generalist middle managers.
14. It is not necessary for the manager of a large-scale
software development project to understand anything
about the technical issues of software development
because a manager’s job is cost and schedule control
and interacting with the buyer.
15. The way we make up for management mistakes is to
require our technical staff to work sixty-plus-hour
weeks for an extended period.
16. We can avoid capital cost for equipment for the
development team by requiring the technical staff to
work three shifts.
17. We generate more revenue and profit by having ten
low-salary people on the project who collectively can't
do the task than by hiring two high-salary people who
can get the job done.
18. So what if he/she quits? We can quickly hire a
replacement.
19. It is against corporate policy to give more than a
5 percent annual raise, so we are losing our network
administrator. The replacement will be hired at a
20 percent higher salary.
11
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 17

BAD EXCUSES RELATED TO

PEOPLE (cont.)

20. He's not a team player if he objects to consistently three days of training per year, of which one day is
working overtime. feel-good training and another day is training on
21. We don’t allow people on our hands-on development corporate policies and business goals.
staff to talk directly to the customers because this will 30. There is nothing that we can do to keep people from
just result in troublemakers making alarmist statements. leaving the company other than giving them a big
22. We won’t meet the schedule because people are raise.
burned out. 31. We can’t give Sam/Sarah a promotion and expose
23. We can handle extreme schedule compression by him/her to the supplier because he/she dresses and acts
offering big bonuses to the staff. like a nerd.
24. We are behind schedule because the buyer’s
requirements result in 40 percent of our staff’s time
being spent in meetings.
25. Our corporate policy is to give poor performers and
outstanding performers essentially the same rewards to
avoid litigation.
26. It’s unrealistic to expect any personnel performance
better than 20 percent of the staff doing 80 percent of
the useful work.
27. We do not report project status or use disciplined
management practices because the technical staff
would not accept it.
28. We don’t involve the hands-on developers in cost
estimation because this is guaranteed to result in a
losing cost estimate.
29. Our corporate management is committed to training.
On average, every member of the technical staff gets

13
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 19
BAD EXCUSES RELATED TO
PROCESS
1. If we follow the organizational process we will
automatically develop software with high productivity
and quality and low cycle time.
2. We do not measure whether use of our organizational
process improves productivity, quality, and user
satisfaction and lowers cycle time because that is not
required.
3. QA people who audit compliance with process do not
need to have any technical understanding.
4. I don’t need good process because I have good people.
5. We are 75 percent complete because the auditors have
determined that 750 out of 1,000 steps in the process
model have been completed.
6. It must be a good process because it takes five large
volumes to document.
7. The only reason our management is interested in the
Software Engineering Institute (SEI) Capability
Maturity Model (CMM) is because they feel Level 3 is
necessary to win DoD contracts.
8. We did not involve our experienced hands-on software
developers in developing our organizational process for
software development because they can’t be spared
from developing software.
9. We do not verify architecture because that is not
included in the organizational process.
10. It will take at least five years to get our software
development organization to follow the latest process
model.
11. Rigidly following a process stifles creativity.
12. Our process is so concurrent and rapid that cost and
schedule control is not possible.
13. The technical staff will not accept the discipline
imposed by a process.
14. Use of automated groupware to constrain the team to
follow a process and activity network is intolerable Big
Brother micromanagement.
15. We’ll give every person on the staff a process manual
and training on how to answer the auditors, but we
don’t expect them to pay much attention to the
organizational process model when they are
developing software.
16. This is a good process because it is repeatable.
17. We will spend the first nine months of the project
doing nothing but defining the processes we will use to
develop the software because, by becoming an SEI
Level 2 organization, we will be way ahead of the game
by the time we complete the project.
18. We have not bothered to define rigorous software
development processes because process is just the latest
software silver bullet which, like all silver bullets, will
be replaced by a new fad in a couple of years.
15
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 21
BAD EXCUSES RELATED TO
SCHEDULE PROBLEMS
1. We can always get out of schedule problems by adding
people.
2. We can always get out of schedule problems by
performing fewer tests.
3. We can make schedule by working overtime.
4. It’s not our fault that a crucial external dependency was
late and caused our delivery to slip.
5. What is schedule compression?
6. We don’t have schedule problems because, when the
calendar time allocated to a task is used up, we end the
task and move on to the next task.
7. It is a success-oriented schedule, but when you
challenge people they do great things.
8. How could we have known before integration test that
the network did not have enough throughput?
9. Our expectations for a highly compressed schedule
didn’t work out, but we will meet the delivery date by
delivering a prototype.
10. We are behind schedule because the buyer can’t
stabilize system requirements.
11. The schedule problem is not requirements volatility; it
is the contractor’s lack of management skill.
12. We don’t use the Budgeted Cost of Work Scheduled
(BCWS) and Budgeted Cost of Work Performed
(BCWP) metrics because those are 1970s technology.
13. We thought we could do more things in parallel
because of the new technology we used for the first
time.
14. This is incremental development. Any schedule slip
will be made up in subsequent releases.
15. We’re behind schedule because we spent too much
time on planning and architecture design.
16. Quality of design will minimize testing.
17. If I schedule to a level of great detail, I'll tie my hands.
18. We will deliver on schedule because we can fix it while
they are using it.
19. What difference does it make if the schedule slips as
long as we don’t have a large cost overrun?
20. Our schedule slip was a vendor’s fault. The vendor of
the Database Management System (DBMS) was late in
delivering version 7.3.
21. We were forced into a schedule we can’t possibly meet
because our buyer didn’t want to give bad news to the
future users.
22. We didn’t meet the schedule because we didn’t know
about the poor quality of the software we planned to
use from the reuse library.
23. Our schedule slipped because the buyer was slow in
approving our intermediate products.
24. Our schedule slipped because another company raided
our technical staff.
17
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 23
BAD EXCUSES RELATED TO COST
AND SCHEDULE CONTROL
1. Formal cost and schedule control always ends up with
variance reports being the primary product.
2. The technical staff will not accept the degree of control
that goes with Earned Value metrics.
3. This is a level-of-effort, delivery-order contract for
software development, so we do not report Earned Value.
4. We can't predict cost and schedule when requirements
are always changing.
5. You can't schedule invention.
6. Five months is too short for a task.
7. The cost we estimated for this project is based on a
productivity five times greater than anything our
organization has done before because we are going to
use a new technology that we've never used before.
8. The reason our cost per line of embedded code for this
new embedded system is estimated to be ten times less
than we've ever had before is that our software will be
90 percent reuse of legacy Ada 83 code from a similar
system, which we will implement in an Object-
Oriented (OO) design.
9. Our cost per line of code for this new system is
estimated to be ten times less than we have ever had
before because this system will integrate GOTS and
COTS software. Our first task under contract will be
to identify this GOTS and COTS software.
10. Our cost estimate is good because we used a cost
estimation tool.
11. The project is doing fine. We estimated we would
have expended $11.3 million by this date and our
actual expenditure is $10.937 million.
12. The project will only experience a 6 percent overrun,
which is excellent. We originally estimated the cost at
completion to be $8 million, and the current estimate
at completion is $8.5 million. The current value of
BCWP is $5 million, and the corresponding actual
cost is $7 million.
13. Our actual expenditure has always been within
5 percent of BCWP. We update our cost/schedule
baseline to actuals once a month.
14. We estimate that this software development project
will take 2,000 staff months of effort and be
completed in seventeen months.
15. Our accounting system cannot collect costs by
WBS tasks.
16. Our proposed cost was a cost that management
thought would make us the lowest bidder.
17. Now that the contract has been awarded, we need to
negotiate what the real cost will be.
18. We can't provide visibility into the status of the software
development because software is a single task at level 4
of the WBS for this embedded weapon system.
19. You won't get visibility into software status because
integrated hardware/software components are at level 3
19
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 25
BAD EXCUSES RELATED TO COST
AND SCHEDULE CONTROL (cont.)
in the WBS and the contract only requires us to report
status to level 2.
20. Yes, there are a number of our tasks that can't begin
before some government action, but we don't include
this dependency in our activity network because we can't
control our customer.
21. We are going to overrun our cost estimate because some
risk items went wrong and DoD regulations will not allow
setting aside a funding reserve for risks that go wrong.
22. We can't have binary exit criteria for most of the tasks in
our activity network because they are level-of-effort tasks.
23. We can't have binary exit criteria for many of our tasks
because they are Time Boxes.
24. We don't plan for workarounds for risk items that go
wrong—that would be a lot of work for nothing, since
most risk items will not go wrong.
25. The new acquisition regulations for the federal
government prohibit the government from closely
monitoring the contractor's cost/schedule status on a
development contract.
26. It was just bad luck that the workaround was on the critical
path when it became clear the risk would go wrong.
27. We can’t accurately plan the date of project completion
because this is incremental development and we only
prepare a detailed activity network for the increment on
which we are currently working.
BAD EXCUSES RELATED TO
REQUIREMENTS DEFINITION AND
MANAGEMENT
1. The users don't know what they want.
2. We don't need people from the field to be involved in
defining system requirements because we have people
in the program office with domain experience.
3. We won't do any prototyping of the user interface
until we’ve finished design, because coding shouldn’t
begin until design is finished.
4. We can't ask the user; we're too far down the road.
5. We are at the leading edge of technology. We can
certainly figure out how to run a mailroom better than
the low-skilled people who work there.
6. This is an OO project so we never stop iterating
among requirements analysis, design, and coding.
7. Future users were involved in requirements
definition—they reviewed the A-spec written by the
development contractor.
8. The system reliability and safety requirements were
allocated to software by the systems engineers because
software is very flexible, and these requirements would
be too hard to implement in hardware.
9. There are no software engineers on the systems
engineering team for this embedded system because
software engineers are not real engineers.
10. This is evolutionary development. We'll define
security and safety requirements after we field the
tenth incremental release.
21
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 27

BAD EXCUSES RELATED TO

REQUIREMENTS DEFINITION AND
MANAGEMENT (cont.)

11. This is evolutionary development, so we won't have
stable requirements until eighteen months after project
start.
12. We have experienced a lot of requirements volatility
and it's all the government's fault.
13. We only trace requirements to the Computer Software
Configuration Item (CSCI) level because the buyer
only requires functional, allocated, and product
baselines to be under configuration control.
14. We can't do requirements traceability because the
CASE tools we are using don't support it.
15. Our requirements traceability information is not up to
date because it takes a lot of time to do this manually.
16. How could we have known before integration test that
modifying this algorithm would have anything to do
with the response time to that user request?
17. We do exhaustive regression testing for every change to
the operational software because you can never know
everything the change might affect.
18. How could we have known that errors in that code
module would cause secure data to be transmitted in
the clear?
19. We can't be sure that system requirements are mapped
correctly into software requirements because we used
different CASE tools for systems engineering and
software design.
20. We can’t use a rigorous methodology for systems
requirements definition because functional people are
defining these requirements and they are not technical.
21. We award the Systems Engineering Technical
Assistance (SETA) contract to the lowest bidder
because that contractor only defines requirements.
22. We are using leading-edge concurrent engineering
methods to define CSCI external interface
requirements in parallel with designing the CSCI.
23. There was no way to know for sure before integration
test that the database stored all the data needed by the
application software, because we used different CASE
tools to design the database and the application
software.
24. There is no top-down requirements traceability
because this is the Demonstration and Validation
Phase.

23
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 29
BAD EXCUSES RELATED TO DESIGN
1. The sooner we begin coding after contract award, the
more successful we are.
2. The architecture will evolve over fifteen releases. This
is evolutionary development.
3. We want a design from which 100 percent of the code
can be automatically generated by a CASE tool.
4. Pseudo-code is design.
5. You can't test the architecture until integration test.
6. What is client/server network-capacity planning?
7. Since none of our software engineers have ever done
OO analysis and design, we have scheduled two days
of training to bring them up the learning curve.
8. We are doing OO design so our application can be
90 percent reuse of legacy software.
9. We don't need a person experienced in this design
method because we are using a CASE tool.
10. We have planned very little cost and schedule for
design because this application will be an integration
of COTS and GOTS software.
11. We don't need a person experienced in designing a
client/server architecture because the network design
will implement the architecture described in the
Defense Information Systems Agency (DISA)
Technical Architecture Framework for Information
Management (TAFIM).
12. We didn't waste time quantifying the future user load
on this network because this network was designed
with more capacity than we'll ever need.
13. We won't know the high-frequency queries on the new
database until the database becomes operational. This
is low risk because we are using an industrial-strength
DBMS.
14. The cost savings are not in reuse of architecture; they
are in reuse of code.
15. Our design is excellent because we devoted 10 percent
of schedule and 3 percent of cost to top-level and
detailed designs.
16. We don't have any time period during development
dedicated to design because our method is RAD and
prototyping.
17. Measuring design complexity is typical of the kind of
idea a technologist would come up with. We're
software developers, not technologists.
18. I can't devote a lot of resources to worrying about the
cost of maintenance because I'm on a tight schedule.
19. The components of the client/server network are
hardware, middleware, and operating system software,
so the network should be designed by systems engineers
before the software developers come on board.
25
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 31
BAD EXCUSES RELATED TO
DESIGN (cont.)
20. This is a war-fighting machine with lots of metal, so the
system architecture should be developed by hardware
systems engineers before the software developers come
on board to start developing the million-plus lines of
code that will control this machine.
21. We don't keep our design representation in the CASE
tool consistent with the source code. It is too hard to
go back and change the design in the CASE tool after
code has been manually added to the code that is
automatically generated by the CASE tool.
22. We can't keep our design representation in the CASE
tool consistent with the source code because we can't
prevent the programmers from changing the source
code automatically generated by the CASE tool.
23. Why should we develop our design around standard
Application Program Interfaces (APIs)? We're not
going to be replacing software components after we
deliver this system.
24. What is a standard API?
25. We can't afford the additional cost of designing for reuse.
26. Our design isolates persistent data from applications
by storing the data in a relational database. Business
rules are coded in the application software because
the programming language is more flexible than
Structured Query Language (SQL).
27. There is not enough time for design. We are driven by
short cycle time.
28. Complexity management gives the theoreticians
something to write about, but this is the real world.
29. If we put design under configuration control, the
programmers will quit.
30. It is an OO design because it is programmed in C++
(Ada 95).
31. We are complying with the good practice of using Ada
by using a code-translation tool that inputs
FORTRAN and outputs Ada.
32. We can’t trace requirements from the system
architecture to software components because the
system is partitioned into functions and the software is
partitioned into classes and objects.
33. It is not a risk that no one on the development team
has ever developed a large relational database. SQL is
a 4GL that is very simple and easy to learn.
27
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 33
BAD EXCUSES RELATED TO QUALITY
1. I don't worry about quality because my customer is
only interested in productivity, cost, and schedule, and
quality has nothing to do with those.
2. Who ever heard of a project specifying a quality goal?
3. You can't measure quality because you never can be
sure how many bugs you have not found.
4. This is an information system, not the Space Shuttle
or a nuclear weapon.
5. You can only go for high productivity or high quality,
not both.
6. We take quality very seriously. QA continuously
audits compliance with the organizational process.
7. We develop high-quality software by complying with
MIL-STD-498 and the International Standards
Organization (ISO) software standards.
8. We are a CMM Level 3 organization and therefore all
of our software is of high quality.
9. We must deliver software of exceptionally high quality,
so we are putting our resources into a very thorough
test program instead of inspections.
10. This project will develop high-quality software because
there is an IV&V contractor.
11. This software will be high quality because it will be
90 percent reuse.
12. What is quality? How do we measure quality?
13. Code-complexity metrics have nothing to do
with quality.
14. Quality is the number of bugs in the delivered software.
15. We shouldn't do more than specified under the
contract. The contract doesn't say anything
about quality.
16. If it doesn't work, we'll fix it later.
17. The customer isn't interested in quality.
18. The quality of these 300,000 Source Lines of Code
(SLOC) is very high. Our verification and testing of
this software found about 5,000 defects from the
inception of development through integration test.
19. The bad news is that the development ended up being
75 percent over the nominal schedule from the cost
model. The good news is that, when projects take
much longer than the nominal schedule, the quality is
much higher.
20. We have a very tight schedule, so we don’t have time
for formal inspections.
21. We have to deliver software with exceptionally high
quality; therefore, we are implementing a thorough
code walkthrough process, because most code errors
occur in source code and it is code errors that have the
most severe impact.
29
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 35

BAD EXCUSES RELATED TO

DOCUMENTATION

1. We don’t need to document the design because we put 11. We won’t document the design so the buyer will have
extensive comments in the source code. no choice but to give us the contract to maintain the
2. We are requiring the contractor to develop every system.
MIL-STD-498 document in full compliance with its 12. We don’t allow our domain experts or development
Data Item Description (DID) because this is required staff to write or review our documentation because all
by MIL-STD-498. technical people are terrible writers.
3. Our cost estimate includes no cost for generating 13. This is a great user’s manual. The first chapter is
documents because all the documentation we need will dedicated to a detailed explanation of how to use a
be automatically generated by CASE tools. mouse.
4. We only use documentation during development
because it costs too much during maintenance to keep
documentation consistent with the code.
5. Metrics show that DoD spends much more on
documentation than the commercial world.
Therefore, all documentation is a waste.
6. Our Software Development Plan is a contractor
format. It leaves out everything that pins us down.
7. The value of a document is directly proportionate to
its weight.
8. MIL-STD-498 is no longer mandatory. Therefore,
there is no need for any documentation.
9. The last thing we do before we deliver the software is
to develop the user’s manual to ensure that it reflects
the as-built system.
10. The document is excellent. It follows the format of
the MIL-STD-498 Data Item Description exactly.

31
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 37

BAD EXCUSES RELATED TO SURPRISE

1. You can’t blame the program manager. How could 9. We are going to have a six-month slip because the
he/she have known the security requirements were organization responsible for a crucial external interface
high risk? Security is technically complex. unexpectedly changed its network operating system.
2. How could we have known before integration test that 10. We can’t deliver the software as scheduled because the
the architecture would not have the required capacity? latest version of a COTS software product integrated
3. Who would have expected that our lead designer into our system has a different API.
would quit to take a job at a different company at
twice the salary? What has become of loyalty to
the company?
4. I could have done something about this disaster if
someone on the technical staff had told me when the
signs first appeared.
5. We’re scheduled to begin integration test and you are
telling me the design hasn’t been completed? We’ll
deliver the rapid prototype and declare success.
6. It’s not our fault that the software is failing integration
test because of bugs in the reuse software. We got this
software from a reuse library.
7. The software won’t execute on the target computer.
The vendor of the Graphical User Interface (GUI)
builder didn’t tell us that the needed run-time library
didn’t exist for that computer.
8. I can’t imagine why the order-processing people using
our new software are objecting to the new way of
doing things. They must not have the education
needed to appreciate the elegance of the new process.

33
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 39
BAD EXCUSES RELATED TO THE
CONTRACT
1. The buyer is claiming that we have not completed the
Statement of Work (SOW) task because he is
interpreting an ambiguous SOW in an unreasonably
stringent way.
2. The cost model in the Request for Proposal (RFP) on
which we made our cost proposal is unrealistic. This is
an evolutionary acquisition and implementation project
in which requirements will be changing for years.
Therefore, there is no way to accurately estimate the cost
at completion now that we are performing on the
contract.
3. The schedule in the Software Development Plan, which
we submitted with our proposal and which is
incorporated into the contract, is not contractually
binding because we cannot control when COTS
vendors will release the needed versions and when the
government will provide Government Furnished
Equipment (GFE) and Government Furnished
Information (GFI).
4. Seventy percent of the lead people listed in our proposal
will not work on the project because of unexpected
problems on their current projects.
5. We overran our cost and schedule projections by
100 percent because the government required us to
program in Ada.
6. This is a time-and-materials, delivery-order contract.
We can’t be held to delivering a product on a schedule.
7. This is a fixed-labor-rate, delivery-order contract in
which our cost estimate was based on the labor-mix
model in the RFP. Our large cost overrun is due to the
fact that we have been constantly surprised with delivery
orders and have had to staff heavily with our highest-
labor-rate people.
8. If the specification in the RFP had said you wanted
wings on both sides of the airplane, we would have bid
it. We're working on an ECP.
9. We have no risk.
10. All of the problems we have been having for the past
year are Sam’s/Sarah’s fault.
11. Trust me. We'll deliver on time.
12. The contractor is being unreasonable and just trying to
hold us up for more funding by telling us that the new
product we want him to produce is outside the scope of
the SOW.
13. The contract requires us to implement a Common
Operating Environment (COE), and one of the reuse
products in the COE is the reason we failed to meet
contract requirements. Therefore the buyer is
responsible for our failure to meet requirements and our
large cost overrun and schedule slip.
35
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 41
BAD EXCUSES RELATED TO CODING
AND TESTING
1. Many of our code units are totally unstructured, with
several unrestricted GOTOs and cyclomatic
complexity greater than 100, because this is necessary
to optimize performance.
2. We don’t do white-box test in unit test because this
software is too large.
3. We meet the DoD requirements for Ada by using code
translation software that inputs COBOL source code
and outputs Ada source code.
4. Our software is OO because the C source code is
compiled with a C++ compiler.
5. During system test on the target system, our practice is
to make patches to the object code when errors are
encountered and then continue testing. It would take
too much time to send the analysis data back to the
development organization to isolate and fix the
problems. Were we to fix these problems in source,
compile them, perform a build, and produce a
Software Version Document (SVD), we would be
talking about ten hours (overnight) of wall-clock time.
If errors occurred in the compile or build process, the
programmers wouldn’t be there to fix them until the
next morning, in which case the new load files
wouldn’t be ready for the next day’s test and the test
sessions for the day would probably be lost. If we had
the programmers work a night shift and generate a
new baseline, there would be a substantial chance that
one of the “fixes” would introduce another error (source
updates when long periods of time have elapsed since
the programmer wrote the code are, after all, the most
error-prone processes in the development of complex
systems). Any error in one of the fixes would scrub the
test sessions for the day.
6. We thoroughly stress this client/server software. The
specification calls for forty users on client workstations,
so we have forty client workstations logged on during
the stress test, with five of these being operated by
testers who use the workstations in any manner they
choose during the test.
7. We can’t define specific loads on the system for the
stress test because we can’t know the real peak loads on
the system until it is fielded.
8. Thirty percent of our source code is assembly language
because this is an optimization needed to meet
performance requirements.
9. We do not have coding standards because standards are
subjective and not all programmers have the same
style. Also, not everyone can achieve the standards set
by the best programmers.
10. Our programmers use text editors that allow them to
modify source code automatically generated from
design by a CASE tool, because you can’t really
understand how the software will work until you write
the code.
37
Excuses 1/99 mid-line 2/1/99 1:41 PM Page 43

THE AIRLIE SOFTWARE COUNCIL

Victor Basili University of Maryland

Grady Booch Rational
Norm Brown Software Program Managers Network
Peter Chen Chen & Associates, Inc.
Christine Davis Texas Instruments
Tom DeMarco The Atlantic Systems Guild
Mike Dyer Lockheed Martin Corporation
Mike Evans Computers & Concepts Associates
Bill Hetzel Qware
Capers Jones Software Productivity Research, Inc.
Tim Lister The Atlantic Systems Guild
John Manzo 3Com
Lou Mazzucchelli Gerard Klauer Mattison & Co., Inc.
Tom McCabe McCabe & Associates
Frank McGrath Software Focus, Inc.
Roger Pressman R.S. Pressman & Associates, Inc.
Larry Putnam Quantitative Software Management
Howard Rubin Hunter College, CUNY
Ed Yourdon American Programmer

39