1

Code Properties

“It is possible to produce truly awful object oriented programs and systems.”

Bjarne Stroustrup

2

The defect density U curve

Defects perKLOC

Average component complexity

For Ada, assembler, C, C++, Cobol, Fortran, Pascal, and PL/M systems:

Ref: Hatton

3

Exploiting the U-curve

Inspect components at the high and low ends preferentially over the medium-sized ones, (i.e. those near the middle of the U-curve).

4

Truncate

In those systems where excessive complexity (or size) has been restricted:-

Defects perNCKSLOC

Average component complexity

5

Avoid deep inheritance

Defect Density v. Inheritance, (Cartwright & Shepperd)

0

0.5

1

1.5

2

2.5

3

3.5

No inheritance Inheritance

Defe

cts

per KLO

C

< Three levels

6

Eliminate Small Components

Defects perNCKSLOC

Average component complexity

7

Effective defect density curve

Defects perNCKSLOC

Size of component with ‘average’ component complexity

8

Fault Density < E

Testing Time (t)

Faultsper1000NCSLOC

E

9

10

Defect Densities

Source Language E Error/NCkSLOC

FormalMethods?

DevelopmentStatus

Operating System

Assembler 6-15 N Release

LanguageParser

C 20-100 N Dev

Scientific Fortran 3 N Release

Air TrafficControl

C 1.25 Y Release

IBM Cleanroom Various 3.4 Y/N Release

IBM Transaction

Various 30 N Release

Apollo Ada & C 0.8 Y Release

A (200 kSLOC) C 0.72 N Release 14

B (50 kSLOC) C++ 1.14 N Release 3

Puerto Rico ProvisioningOne million L OC

C 0.6 N AcceptanceTest

11

Defect Densities in 2008

• After Release, count all defects and use asymptotic values (E)

The current state of the art for Reliable systems 0.5-1 defects / NCSKLOC,

A reasonable commercial system

3-6 defects / NCSKLOC, A poor system is likely to have

> 15 defects / NCSKLOC .

12

Impact of programming language

Defect density is relatively independent of programming language, so• Moving from assembler to any 3GL is a good

idea.• Moving from one 3GL to another is a bad

idea.• Moving from a 3GL to an OO language is a

good idea, iff it is industrial strength

13

Inspections

A significant step defect removal:• The evidence suggests that they are 5-10

times more efficient than any other form of defect removal.

• The technology is mature, (some 20 years old), and in trained hands, exceptionally effective.

• But, too often become bureaucratic.

14

Ignoring Inspections

This impressive performance is rewarded by being ignored by most of the computing industry

• Time-to-Market Pressure

• Managers punish errors

• Gurus do not suffer fools lightly

• Bureaucratic Check Lists

15

Alcatel Inspections circa 1995

0

20

40

60

80

100

120

140

160

Code review Module test Integrationtest

System test

Development cyclewithout code review

Development cycle withcode review

16

Inspections

Rate of faults found per hour,

LiveRunning

Black Box White Box Inspections0

0.20.40.60.8

11.2

LiveRunning

Black Box White Box Inspections

17

Code Inspection Process

1. Inspect newcomers code.

2. Inspect code if bugs are found in system test.

3. Inspect code where there is a long history of change.

4. Measure Code Complexity and inspect the outliers.

5. Ask all programmers to have their code read by someone else.

18

Consider using Formal Methods

• They can be are effective, but are not a quantum leap. It depends!

• 3:1 defect density reduction is possible

• They only appear to work in conjunction with other techniques. – Beware of over-reliance on them– In many system there are algorithms which you

can’t get right any other way. – But they confuse customer and developers

19

Defects demographics, CAA Study 1997

Perc

en

t o

f a

ll d

efe

cts

0

10

20

30

40

50

60

70

Code review Unit testing System /

acceptance

testing

This data tentatively suggests that either formal specificationslead to unusual fault distributions or that they lead tono code inspections.

20

CAA study of Formal methods

CAA CDIS air-traffic system

Fa

ult

s p

er

KL

OC

0

5

10

15

20

25

Pre-

delivery

Post-

delivery

19.6

0.58

21

1.61

Formal

Informal

21

Objects can be horrid

Recent studies (Humphrey, Hatton, Tichy, Shepherd & Cartwright) together show:

• C++ OO systems have almost 25% more defects than conventional C or Pascal systems.

• Each defect in a C++ OO system takes between 2 and 3 times longer to fix than a conventional system. This is true for both simple defects AND difficult ones. The whole distribution is right shifted.

• Components involved in inheritance have 6 times more defects than non-inheritance components.

22

Object-orientation observation

Per

cent

of a

ll fix

es

0

10

20

30

40

50

60

70

80

90

100

< 1

hou

r

< 2

hou

rs

< 5

hou

rs

< 1

0 ho

urs

< 2

0 ho

urs

< 5

0 ho

urs

< 1

00 h

ours

< 2

00 h

ours

C++

C

But I have no doubts. Poor code can be produced anytime and anywhere.

Les Hatton

23

Common C++ Errors

1. Writing ‘ = ‘when you mean ‘==‘

2. Function calls without parameters

3. String duplications

4. Deleting Arrays and Strings

5. Trailing ‘;’ after class declarations

6. Floats, integers and casting

7. Uninitialized pointers

8. Memory Leaks

9. Calling a program "test"

24

Release Documents

• Describe features• Describe corrections to troubles• Cross reference software dependencies• Specify limitations or deficiencies• Provide special installation instructions• Provide data conversion instructions• Specify training• Identify new, changed or deleted documents• Maintain software source code• Maintain product lists

25

Coding Style

If (cond A) If (cond A)Execute process A Execute Process A

If (cond B) If (cond B)Execute process B Execute Process B

else If (cond C)Execute process C Execute Process

else "check dispatch parameter"

26

What is the value of k in a Process consisting

of thread A & thread B?

initialize k=4

thread A: thread B:

1A. load k into T 1B. load k into T

2A. ADD 1 to T 2B. ADD 2 to T

3A. store T into k 3B store T into k

27

Multi-Core

• Hardware strongly constrains software

• Compute bounded applications

• Look for algorithms with data level parallelism

• Multithread designs

• Double Buffer decouples I/O and application processing.

• Variable latency applications induce stalls

28

Multithreading increases software complexity

• Load balancing

• Concurrency controlling

• Debugging tools

• Designs for parallel execution requires special know-how

29

Multithreading Compilers provide

• Automatic thread definition

• Adding data transfers

• Concurrency control

• Deadlock avoidance

• Memory sharing among threads

• Memory optimization within threads

• Thread scheduler/dispatcher linkage

30

Heisenbugs

Latent faults causing gradual deterioration a software process with respect to the use of some resource resulting in a crash.

31

Case Study: System Administration System

• System monitors equipment.

• Messages are trigger by events

• I/O Buffer Sharing reduces memory required.

32

Trouble Reported

Intermittent hangs reported in the field.

33

Failure Analysis

• Latent Fault in Buffer Flow Control.

• Software does not return ‘buffer full’ signal.

• Messages written to full buffers.

• Messages accepted and partially dropped.

• Application waits for complete message.

34

Solution

• Fix the bug by returning appropriate indicator, or

• Re-launch message handler and avoid the problem:

• When buffers are half full.• Periodically.• After hang is detected.

35

Feb 2008 SurveyUsers that expect to any FOSS Office Suite

instead of Microsoft Office in 2008

05

101520253035404550

Zero 25% to50%

100%

%

36

Survey• How will Open Source products reduce your

2008 software budget form 2007?

0

5

10

15

20

25

30

35

40

0 10%to

20%>20%

%

37

How much will FOSS products reduce software budgets?

0

5

10

15

20

25

30

35

40

zero <10% 10% to 20% >20%

%

38

Software requirements that expect to be met with FOSS

0

5

10

15

20

25

30

35

40

45

50

0 <25% 25%to50% >50%

%

39

40