code complete a practical handbook

Welcome to Software Construction Page 4 H:\books\CodeC2Ed\Reviews\Web\01-Welcome.doc Detailed Design Integration Unit Testing Integration Testing Requirements Development Problem Defini

Code Complete Preface Page i

Code Complete Preface Page iii

Programming language books

Magazine articles

Other software books

Technology references

Complete software-construction reference

Code Complete Preface Page v

Discussions about construction have also been hobbled by the suggestion that

Code Complete Preface Page vii

When art critics get

together they talk about

Form and Structure and

Meaning When artists

get together they talk

about where you can buy

cheap turpentine

—Pablo Picasso

CC2E.COM/ 1234

Notes about the Second

Code Complete Notes about the Second Edition Page ii

“The word “incremental” has never achieved the

Code Complete Notes about the Second Edition Page iv

Code Complete 1 Welcome to Software Construction Page 2

RequirementsDevelopment

Software

Testing

DetailedDesign

Coding andDebuggingConstruction

Planning

Integration

CorrectiveMaintenance

UnitTesting

IntegrationTesting

Code Complete 1 Welcome to Software Construction Page 4

H:\books\CodeC2Ed\Reviews\Web\01-Welcome.doc

Detailed Design

Integration

Unit Testing

Integration Testing

Requirements Development

Problem Definition

Software Architecture

System Testing

Corrective Maintenance

Construction Planning

Coding and Debugging

For an even fuller list of construction activities, look through the chapter titles in

details on the relationship

between project size and the

percentage of time consumed

by construction, see “Activity

Proportions and Size” in

Section 27.5

Code Complete 1 Welcome to Software Construction Page 6

data on variations among

programmers, see “Individual

Variation” in Section 28.5

KEY POINT

Code Complete 2 Metaphors for a Richer Understanding of Software Development Page 1

The history of science is full of discoveries based on exploiting the power of

Code Complete 2 Metaphors for a Richer Understanding of Software Development Page 3

reduced Learning and

education are quicker In

effect, metaphors are a

way of internalizing and

In fact, many models that have been replaced by better models are still useful

software, see “Design is a

Heuristic Process” in Section

5.1

Code Complete 2 Metaphors for a Richer Understanding of Software Development Page 5

favorite hunting dog to enjoy a “literate program” the way you would a good

Plan to throw one away;

you will, anyhow

— Fred Brooks

If you plan to throw one

away, you will throw

away two

— Craig Zerouni

Code Complete 2 Metaphors for a Richer Understanding of Software Development Page 7

maintenance, see the chapter

“On the Origins of Designer

Intuition” in Rethinking

Systems Analysis and Design

(Weinberg 1988)

Code Complete 2 Metaphors for a Richer Understanding of Software Development Page 9

Code Complete 2 Metaphors for a Richer Understanding of Software Development Page 11

Careful planning doesn’t necessarily mean exhaustive planning or over-planning

Code Complete 2 Metaphors for a Richer Understanding of Software Development Page 13

some good comments about

extending the construction

metaphor, see “What

Supports the Roof?” (Starr

design, see Section 5.3,

“Design Building Blocks:

Heuristics.”

CC2E.COM/ 0285

Kuhn, Thomas S The Structure of Scientific Revolutions, 3d Ed., Chicago: The

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 1

jewel, you have to start with a diamond in the rough If you start with plans for a

Pay-ing attention to quality is also

the best way to improve

pro-ductivity For details, see

Section 20.5, “The General

Principle of Software

Qual-ity.”

KEY POINT

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 3

The methodology used

should be based on choice

of the latest and best, and

not based on ignorance

It should also be laced

liberally with the old and

development program that

that cultivates these skills,

see Chapter 16 of

Profes-sional Software Development

(McConnell 2004)

do upstream work, the recommendation to “do more upstream work” sounds like

many entertaining variations

on this theme, read Gerald

Weinberg’s classic, The

Psy-chology of Computer

Pro-gramming (Weinberg 1998)

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 5

to find out what they really want But that’s cheaper than building the wrong

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 7

quire-tecture

Archi-struc-tion

Con-System Test

Re-lease

We Have Learned About Fighting Defects” (Shull et al 2002), and Balancing Agility

Introduced

RequirementsArchitectureConstruction

System test

Requirements

Phase in Which a Defect Is Detected

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 9

Business Systems

Mission-Critical Systems

Embedded Critical Systems

Life-Typical Good Practices

Kind of Software

Business Systems

Mission-Critical Systems

Embedded Critical Systems

Life-Typical plications

ap-Internet site Intranet site Inventory manage-ment

Games Management infor-mation systems Payroll system

Embedded software Games

Internet site Packaged software Software tools Web services

Avionics software Embedded software Medical devices Operating systems Packaged software

Lifecycle models

Agile development (extreme program-ming, scrum, time-box development, and so on) Evolutionary proto-typing

Staged delivery Evolutionary deliv-ery

Spiral development

Staged delivery Spiral development Evolutionary deliv-ery

Planning and management

Incremental project planning

As-needed test and

QA planning Informal change con-trol

Basic up-front ning

plan-Basic test planning As-needed QA plan-ning

Formal change trol

con-Extensive up-front planning

Extensive test ning

Extensive QA ning

plan-Rigorous change control

ments

Require-Informal ments specification

requiSemi-formal quirements specifica-tion

re-As-needed ments reviews

require-Formal requirements specification Formal requirements inspections

Design Design and coding

are combined

Architectural design Informal detailed design

As-needed design reviews

Architectural design Formal architecture inspections Formal detailed de-sign

Formal detailed sign inspections Construction Pair programming or

de-individual coding Informal check-in procedure or no check-in procedure

Pair programming or individual coding Informal check-in procedure As-needed code re-views

Pair programming or individual coding Formal check-in pro-cedure

Formal code tions

inspec-Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 11

H:\books\CodeC2Ed\Reviews\Web\03-PrerequisitesHighLevel.doc

Typical Good Practices

Kind of Software

Business Systems

Mission-Critical Systems

Embedded Critical Systems

develop-Little or no testing by

a separate test group

Developers test their own code

Test-first ment

develop-Separate testing group

Developers test their own code

Test-first ment

develop-Separate testing group

Separate QA group Deployment Informal deployment

procedure

Formal deployment procedure

Formal deployment procedure

Project tion status

comple-Cost of Work

Cost of Rework

Cost of Work

Cost of Rework

comple-Cost of Work

Cost of Rework

Cost of Work

Cost of Rework10% $100,000 $20,000 $100,000 $10,000 20% $100,000 $20,000 $100,000 $10,000

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 13

H:\books\CodeC2Ed\Reviews\Web\03-PrerequisitesHighLevel.doc

30% $100,000 $20,000 $100,000 $10,000 40% $100,000 $20,000 $100,000 $10,000 50% $100,000 $20,000 $100,000 $10,000 60% $100,000 $20,000 $100,000 $10,000 70% $100,000 $20,000 $100,000 $10,000 80% $100,000 $20,000 $100,000 $10,000 90% $100,000 $20,000 $100,000 $10,000 100% $100,000 $20,000 $100,000 $10,000 End-of-Project

The extent to which prerequisites need to be satisfied up front will vary with the

details on how to adapt your

development approach for

programs of different sizes,

see Chapter 27, “How

Pro-gram Size Affects

Construc-tion.”

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 15

FutureImprovements

If the ‘box’ is the

bound-ary of constraints and

conditions, then the trick

is to find the box Don’t

think outside the box—

find the box.”

—Andy Hunt and Dave

Thomas

The problem definition should be in user language, and the problem should be

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 17

Requirements are like

water They’re easier to

build on when they’re

frozen

—Anon

HARD DATA

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 19

details on handling changes

to design and code, see

Sec-tion 28.2, “ConfiguraSec-tion

Management.”

is their suggesting changes so frequently that you can’t keep up Having a

details on development

ap-proaches that support flexible

requirements, see Rapid

De-velopment (McConnell

1996)

details on iterative

develop-ment approaches, see

“Iter-ate” in Section 5.4 and

Sec-tion 29.3, “Incremental

Inte-gration Strategies.”

details on the differences

between formal and informal

projects (often caused by

differences in project size),

see Chapter 27, “How

Pro-gram Size Affects

Construc-tion.”

CC2E.COM/ 0323

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 21

more information on design

at all levels, see Chapters 5

through 9

KEY POINT

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 23

details on lower-level

pro-gram design, see Chapters 5

ganizational alternatives, the architecture provides the rationale for the system

details on different size

build-ing blocks in design, see

“Levels of Design” in Section

5.2

mizing what each building

block knows about other

building blocks is a key part

of information hiding For

details, see “Hide Secrets

details on working with

vari-ables, see Chapters 10

through 13

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 25

And it should describe the level at which I/O errors are detected: at the field,

excellent discussion of

soft-ware security, see Writing

Secure Code, 2d Ed (Howard

and LeBlanc 2003) as well as

the January 2002 issue of

IEEE Software

additional information on

designing systems for

per-formance, see Connie

Smith’s Performance

Engi-neering of Software Systems

(1990)

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 27

● Is error detection active or passive? The system can actively anticipate

consistent method of

hdling bad parameters is

an-other aspect of

error-processing strategy that

should be addressed

architec-turally For examples, see

Chapter 8, “Defensive

Pro-gramming.”

good introduction to fault

tolerance, see the July 2001

issue of IEEE Software In

addition to providing a good

introduction, the articles cite

many key books and key

articles on the topic

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 29

a list of kinds of

commer-cially available software

components and libraries, see

“Code Libraries” in Section

30.3

details on handling changes

systematically, see Section

28.2, “Configuration

Man-agement.”

Design bugs are often

subtle and occur by

evolution with early

assumptions being

forgotten as new features

or uses are added to a

system

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 31

a full explanation of delaying

commitment, see “Choose

Binding Time Consciously”

in Section 5.3

more information about how

quality attributes interact, see

Section 20.1, “Characteristics

of Software Quality.”

pose of a program is to exercise a specific machine or language, this guideline

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 33

3.6 Amount of Time to Spend on Upstream

amount of time you spend on

prerequisites will depend on

your project type For details

on adapting prerequisites to

your specific project, see

Section 3.2, “Determine the

Kind of Software You’re

Working On,” earlier in this

Changes During

Construc-tion” in Section 3.4, earlier in

this chapter

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 35

Cockburn, Alistair Writing Effective Use Cases, Boston, Mass.: Addison

Code Complete 3 Measure Twice, Cut Once: Upstream Prerequisites Page 37

Checklist: Upstream Prerequisites

Code Complete 4 Key Construction Decisions Page 1

problems, and in effect increases the mental power of the race

Code Complete 4 Key Construction Decisions Page 3

oriented capabilities.” This phenomenon has been reported throughout the

Code Complete 4 Key Construction Decisions Page 5

Kind of Program Best Languages Worst Languages

Command-line Cobol, Fortran, SQL -

Code Complete 4 Key Construction Decisions Page 7

H:\books\CodeC2Ed\Reviews\Web\04-PrerequisitesProgramming.doc

processing Cross-platform development

Java, Perl, Python Assembler, C#, Visual Basic Database manipulation SQL, Visual Basic Assembler, C

Direct memory manipulation

Assembler, C, C++ C#, Java, Visual Basic Distributed system C#, Java -

Dynamic memory use C, C++, Java - Easy-to-maintain

program

C++, Java, Visual Basic Assembler, Perl

Fast execution Assembler, C, C++,

Visual Basic

JavaScript, Perl, Python

For environments with limited memory

Assembler, C C#, Java, Visual Basic

Mathematical calculation

Basic

Assembler, Java

String manipulation Perl, Python C Web development C#, Java, JavaScript,

more details on the power of

conventions, see Sections

11.3 through 11.5

each class as a faithful part of a comprehensive design Any large program

Code Complete 4 Key Construction Decisions Page 9

careful, over time some of my VB “forms” would end up containing business

Code Complete 4 Key Construction Decisions Page 11

more details on quality

assurance, see Chapter 20,

“The Software-Quality

Landscape.”

Code Complete 5 Design in Construction Page 1

details on the different levels

of formality required on large

and small projects, see

Chapter 27, “How Program

Size Affects Construction.”

projects benefit from careful design just as larger projects do, and recognizing

difference between heuristic

and deterministic processes is

described in Chapter 2,

“Metaphors for a Richer

Understanding of Software

Development.”

Code Complete 5 Design in Construction Page 3

deriving his design in a

rational, error-free way

from a statement of

requirements is quite

unrealistic No system has

ever been developed in

that way, and probably

none ever will Even the

small program

developments shown in

textbooks and papers are

unreal They have been

revised and polished until

the author has shown us

what he wishes he had

done, not what actually

did happen

—David Parnas and Paul

Clements

Design is a Sloppy Process

fuller exploration of this

viewpoint, see “A Rational

Design Process: How and

Why to Fake It” (Parnas and

Clements 1986)

a better answer to this

question, see “How Much

Design is Enough?” in

Section 5.4 later in this

chapter