Structured

Interviews

on

the

Object-Oriented

Paradigm

-LSB-

-RSB-

J

Daly

M

Wood

A

Brooks

J

Miller

and

M

Roper

Empirical

Foundations

of

Computer

Science

-LRB-

EFoCS

-RRB-

Abstract

The

method

of

structured

interviewing

is

an

appropriate

means

of

conducting

a

primary

investigation

when

beginning

a

programme

of

research

involving

different

empirical

techniques

because

-LRB-

i

-RRB-

interviewing

experienced

users

from

academia

and

industry

should

determine

if

academics

are

exploring

issues

that

industrialists

deem

important

-LRB-

ii

-RRB-

interviewing

users

from

industry

helps

provide

external

validity

-LRB-

iii

-RRB-

users

of

object-oriented

systems

have

their

own

views

on

the

benefits

and

drawbacks

of

the

paradigm

These

opinions

could

then

be

used

as

evidence

to

decide

whether

an

empirically

unsupported

practice

is

justified

and

warrants

further

more

controlled

investigation

and

-LRB-

iv

-RRB-

these

views

can

identify

issues

that

have

not

been

previously

considered

Structured

interviews

each

based

on

a

template

of

questions

were

carried

out

with

experienced

object-oriented

users

to

explore

problems

discussed

in

the

object-oriented

literature

concerned

with

high

level

system

understanding

inheritance

software

maintenance

and

other

issues

Interviews

lasted

between

minutes

and

hours

Analysis

undertaken

by

transcripting

and

summarizing

each

interview

and

tabulating

subject

's

answers

to

each

question

discovered

opinions

similar

to

those

expressed

in

the

literature

These

include

the

steepness

of

the

learning

curve

the

difficulties

of

understanding

created

by

inheritance

missing

documentation

and

inappropriate

design

the

tendency

of

systems

to

degrade

as

a

consequence

of

software

maintenance

and

the

view

that

C++

is

inferior

to

purer

OO

languages

Computer

Science

University

of

Strathclyde

Livingstone

Tower

Richmond

Street

Glasgow

U.K.

-LRB-

-RRB-

141 552 4400

jd@cs.strath.ac.uk

Introduction

Performing

empirical

work

is

a

way

of

building

a

cohesive

body

of

knowledge

within

software

engineering

Fenton

et

al

-LSB-

-RSB-

for

example

recently

argued

the

importance

of

experimentation

to

provide

empirical

evidence

for

proposed

new

software

development

and

maintenance

practices

Brooks

et

al

-LSB-

-RSB-

Jones

-LSB-

-RSB-

and

Henry

et

al

-LSB-

-RSB-

make

similar

arguments

Evidence

may

be

derived

from

any

empirical

technique

for

example

through

controlled

laboratory

experiments

introspection

questionnaires

structured

interviews

or

thinking-aloud

protocol

analysis

Although

each

technique

provides

different

empirical

data

-LRB-

for

example

the

structured

interview

promotes

detailed

expert

knowledge

elicitation

whilst

a

laboratory

based

experiment

yields

raw

performance

data

concerned

with

time

and

accuracy

-RRB-

it

is

argued

that

these

techniques

can

complement

one

another

If

an

effect

has

been

demonstrated

by

two

or

more

different

empirical

techniques

it

is

more

likely

that

the

findings

-LRB-

a

-RRB-

are

reliable

and

-LRB-

b

-RRB-

will

be

accepted

by

the

software

engineering

community

When

the

results

are

consistent

the

empirical

techniques

are

said

to

have

confirmatory

power

Another

approach

views

a

series

of

different

empirical

techniques

as

evolutionary

the

important

issues

discovered

by

the

initial

exploratory

study

are

investigated

further

by

the

next

study

and

so

forth

Eventually

hypotheses

are

tested

by

more

focused

empirical

inquiry

It

is

the

intention

of

our

programme

of

research

to

conduct

an

exploratory

investigation

through

structured

interviews

followed

by

questionnaires

to

confirm

the

findings

across

a

wider

user

group

followed

by

laboratory

experiments

to

test

the

findings

in

a

more

controlled

setting

Of

course

in

an

evolutionary

programme

of

research

the

results

from

each

technique

may

turn

out

to

confirm

one

another

Confirmatory

power

can

also

be

achieved

through

external

replication

a

researcher

independently

attempts

to

repeat

the

results

of

an

empirical

study

If

successful

the

replication

provides

supporting

evidence

if

unsuccessful

it

may

have

the

ability

to

challenge

the

original

findings

-LRB-

see

-LSB-

-RSB-

and

-LSB-

-RSB-

for

details

-RRB-

Advocates

of

the

object-oriented

paradigm

have

made

many

claims

about

the

benefits

of

the

paradigm

most

of

which

remain

empirically

unsubstantiated

Jones

-LSB-

-RSB-

for

example

details

a

visible

lack

of

empirical

data

to

support

the

assertions

of

substantial

gains

in

software

productivity

and

quality

reduction

in

defect

potential

and

improving

defect

removal

efficiency

and

software

design

and

component

reuse

Evidence

is

slowly

beginning

to

filter

through

in

certain

areas

but

is

by

no

means

thoroughly

conclusive

For

example

Wilde

and

Huitt

-LSB-

-RSB-

quote

Mancl

and

Havanas

-LSB-

-RSB-

as

providing

evidence

for

extensive

reuse

of

software

objects

and

easier

maintenance

through

better

data

encapsulation

but

their

study

lacks

the

reported

detail

to

convince

the

strongest

skeptics

In

contrast

problems

with

object-oriented

software

are

now

beginning

to

be

realised

For

example

an

empirical

study

by

Dvorak

-LSB-

-RSB-

provides

initial

evidence

of

a

degradation

effect

identified

as

conceptual

entropy

of

class

hierarchies

something

which

requires

further

investigation

So

there

is

a

need

to

provide

stronger

empirical

evidence

than

currently

exists

Structured

interviewing

is

an

appropriate

method

to

initiate

evidence

gathering

for

several

reasons

First

interviewing

experienced

users

from

academia

and

industry

should

determine

if

academics

are

exploring

issues

that

industrialists

deem

important

i.e.

do

academics

and

industrialists

have

similar

or

differing

opinions

on

object-oriented

issues

Second

interviewing

users

from

industry

provides

external

validity

in

the

form

of

real

world

data

something

which

in

more

controlled

experimentation

is

difficult

to

provide

Third

object-oriented

users

have

their

own

opinions

on

the

advantages

and

disadvantages

of

the

paradigm

these

opinions

could

be

used

as

evidence

to

decide

whether

an

empirically

unsupported

practice

is

justified

and

warrants

further

more

controlled

investigation

And

fourth

these

views

can

identify

issues

that

have

not

been

previously

considered

The

structured

interview

requires

a

template

from

which

the

interview

can

be

directed

The

subject

may

give

an

answer

which

is

deemed

worthy

of

pursuing

and

the

interviewer

can

then

ask

supplementary

questions

-LRB-

though

care

must

be

taken

not

to

bias

the

the

interview

direction

-RRB-

Once

satisfied

the

interviewer

returns

to

the

next

question

on

the

template

The

remainder

of

this

paper

is

partitioned

as

follows

Section

discusses

some

of

the

advantages

and

disadvantages

of

structured

interviewing

Section

presents

the

detailed

motivation

for

carrying

out

this

work

with

Section

detailing

the

actual

interview

method

Section

provides

analysis

and

discussion

of

the

data

and

Section

draws

conclusions

Interviewing

as

an

empirical

technique

Interviewing

is

an

appropriate

means

for

conducting

a

primary

investigation

which

offers

many

positive

aspects

First

there

is

the

issue

of

external

validity

Interviewing

experienced

subjects

allows

gathering

of

real

world

data

which

is

of

extreme

importance

for

drawing

real

world

conclusions

For

example

if

a

number

of

experienced

users

hold

the

same

opinion

on

a

particular

issue

the

likelihood

is

an

effect

of

some

kind

exists

further

investigation

is

warranted

Second

as

noted

by

Sinclair

-LSB-

-RSB-

interviewing

is

a

flexible

technique

for

example

it

does

not

have

the

rigidness

of

a

questionnaire

survey

and

it

allows

data

to

be

gathered

relatively

quickly

and

unhindered

Interesting

points

made

by

the

subject

can

be

explored

in

depth

by

efficient

question

probing

Furthermore

feedback

from

initial

interviews

can

be

used

to

refine

the

template

to

concentrate

on

issues

that

were

not

previously

considered

Conversely

refinement

can

also

remove

issues

which

were

initially

considered

to

be

important

but

which

on

discussion

appear

less

significant

i.e.

the

interview

template

can

be

re-oriented

if

necessary

without

major

disruption

to

the

study

as

long

as

the

detail

is

reported

in

the

findings

Third

again

noted

by

Sinclair

-LSB-

-RSB-

there

is

ability

of

the

interviewer

to

motivate

the

subject

to

give

more

information

about

a

topic

as

well

as

being

able

to

direct

and

accelerate

the

information

flow

Finally

there

is

the

advantage

of

being

able

to

re-interview

the

subject

to

further

investigate

points

made

previously

This

allows

clarification

of

opinions

and

as

such

is

an

advantage

that

other

empirical

techniques

e.g.

questionnaires

do

not

readily

allow

As

important

however

is

to

realise

that

there

exists

problems

in

collecting

and

analysing

data

from

structured

interviews

First

there

is

the

danger

of

subjects

saying

what

they

think

is

appropriate

to

say

For

example

if

the

subject

being

interviewed

thinks

that

the

listener

is

superior

then

according

to

Bainbridge

-LSB-

-RSB-

there

may

be

pressures

to

appear

rational

knowledgeable

and

correct

or

inversely

the

subject

may

become

uncooperative

or

present

a

particular

attitude

to

the

topic

Moreover

there

is

also

the

problem

that

while

an

experienced

subject

may

be

opinionated

and

talk

freely

on

the

topic

they

may

not

mention

what

they

think

should

appear

obvious

Second

most

people

think

more

quickly

than

they

talk

-LRB-

especially

if

time

pressures

exist

on

the

subject

e.g.

the

subject

is

being

asked

to

speak

their

thoughts

while

performing

a

task

of

some

description

-RRB-

this

underlies

the

general

point

that

verbally

communicated

data

may

only

give

a

limited

sample

of

the

total

knowledge

of

the

subject

under

study

that

is

only

a

subset

of

their

cognitive

activity

may

be

reported

Third

there

might

be

social

influences

if

the

subject

thinks

what

they

say

can

be

held

against

them

then

they

may

report

what

they

think

the

interviewer

wishes

to

hear

And

fourth

the

interviewer

must

have

a

good

working

knowledge

of

the

domain

being

questioned

without

it

important

aspects

of

the

interview

may

be

left

as

ambiguous

unresolved

or

simply

unnoticed

Unfortunately

there

are

no

objective

independent

techniques

for

doing

analyses

on

such

data

Consequently

this

may

lead

to

problems

for

the

analyser

who

may

have

to

make

assumptions

when

interpreting

what

the

subject

has

mentioned

or

use

their

own

knowledge

of

the

domain

to

make

particular

inferences

For

these

reasons

again

according

to

Bainbridge

-LSB-

-RSB-

many

academic

psychologists

feel

strongly

that

verbal

data

has

limited

importance

interviewer

's

bias

can

creep

in

Also

there

are

high

costs

involved

in

terms

of

time

and

effort

to

fully

analyse

verbal

data

for

example

Neilson

-LSB-

-RSB-

cites

Marchioni

-LSB-

-RSB-

as

quoting

the

need

to

spend

about

hours

for

each

hour

of

subject

observation

on

tasks

such

as

transcribing

video

tapes

and

coding

detailed

protocol

analysis

Neilson

refutes

this

however

and

reckons

in

realistic

development

situations

each

hour

of

thinking-aloud

observation

only

needs

half

an

hour

of

combined

analysis

and

report

writing

In

our

experiences

of

transcripting

and

analysing

structured

interviews

we

found

Marchioni

's

estimate

reasonably

accurate

As

a

consequence

although

conclusions

drawn

are

unlikely

to

stand

firm

unless

large

numbers

of

users

are

interviewed

it

is

important

to

emphasize

that

this

technique

is

helpful

-LRB-

i

-RRB-

for

gaining

insight

into

others

knowledge

-LRB-

ii

-RRB-

for

gaining

insight

into

users

opinions

about

published

problems

and

advocates

claims

and

-LRB-

iii

-RRB-

as

initial

evidence

for

justifying

further

empirical

investigation

Papers

in

the

literature

have

used

similar

techniques

such

as

thinking-aloud

protocols

and

knowledge

acquisition

through

video

recording

apparently

with

success

-LRB-

see

for

example

-LSB-

-RSB-

and

-LSB-

-RSB-

-RRB-

However

as

Lashley

quoted

in

Ericsson

and

Simon

-LSB-

-RSB-

states

introspection

may

make

the

preliminary

survey

but

it

must

be

followed

by

the

chain

and

transit

of

objective

measurement

We

strongly

agree

with

this

statement

and

believe

it

can

also

be

applied

to

the

concept

of

interviewing

we

therefore

discuss

future

work

from

this

primary

research

in

the

conclusions

For

a

more

comprehensive

discussion

of

the

pros

and

cons

of

verbal

data

see

-LSB-

-RSB-

-LSB-

-RSB-

and

-LSB-

-RSB-

Motivation

and

related

work

Many

unsupported

claims

have

been

made

for

the

object-oriented

paradigm

for

example

gains

in

software

productivity

and

quality

reduction

of

development

time

enables

better

prototyping

and

iterative

development

ease

of

software

design

and

component

reuse

facilitates

change

ease

of

understanding

ease

of

maintenance

and

reduction

in

defect

potential

and

improving

defect

removal

efficiency

Henry

et

al

-LSB-

-RSB-

provide

a

list

of

references

which

they

state

have

made

claims

as

having

qualitative

appeal

but

little

supporting

quantitative

data

In

contrast

recent

research

has

started

to

discover

problems

with

the

object-oriented

approach

particularly

in

the

areas

of

software

maintenance

inheritance

polymorphism

and

dynamic

binding

These

problems

are

now

discussed

Wilde

and

Huitt

-LSB-

-RSB-

present

a

comprehensive

report

on

what

they

see

as

several

failings

of

object-oriented

programming

First

object-oriented

languages

complicate

the

tracing

of

dependencies

by

making

use

of

dynamic

binding

of

messages

to

specific

methods

Second

inheritance

it

is

argued

can

make

understanding

a

single

line

of

code

a

difficult

task

because

it

may

require

tracing

a

line

of

method

invocations

Furthermore

inheritance

can

cause

modification

problems

e.g.

if

modifying

a

class

X

then

a

maintainer

must

be

concerned

with

possible

side

effects

in

subclass

Y.

Third

the

dispersion

of

functionality

into

different

object

classes

may

make

the

process

of

software

reuse

and

maintenance

inefficient

because

of

difficulty

in

locating

all

the

required

code

Fourth

polymorphism

can

introduce

subtle

errors

through

inconsistent

naming

e.g.

if

a

system

has

several

implementations

of

a

method

which

have

significantly

different

effects

then

a

maintainer

may

be

mislead

when

interpreting

the

code

and

then

introduce

errors

when

changes

are

being

made

Finally

it

is

argued

that

high

level

system

understanding

can

be

hampered

because

the

traditional

module

calling

hierarchy

is

replaced

by

a

hierarchy

of

methods

A

hierarchy

of

methods

offers

several

difficulties

because

of

the

dynamic

binding

problem

mentioned

above

there

may

be

no

main

or

controlling

system

method

which

is

usually

a

good

starting

point

and

a

hierarchy

of

methods

detracts

from

the

grouping

of

methods

within

objects

These

points

assume

that

only

the

source

code

is

available

however

there

is

no

mention

of

documentation

which

if

availble

is

likely

to

ease

these

problems

In

a

similar

paper

Wilde

et

al

-LSB-

-RSB-

report

that

while

object-orientation

facilitates

change

it

can

also

make

programs

harder

to

understand

for

maintainers

The

issues

addressed

in

-LSB-

-RSB-

are

reexamined

and

the

authors

state

-LSB-

the

-RSB-

different

appearance

and

organization

of

object-oriented

code

may

startle

many

programmers

and

their

traditional

approaches

to

program

understanding

may

break

down

-LSB-

-RSB-

They

conclude

that

it

will

take

years

to

identify

all

the

problems

with

maintenance

of

object-oriented

software

systems

and

as

such

any

likely

problem

areas

should

be

closely

monitored

Kung

et

al

-LSB-

-RSB-

reiterate

some

of

the

problems

reported

by

Wilde

et

al

-LSB-

-RSB-

-LSB-

-RSB-

arguing

that

the

new

characteristics

of

object-orientation

-LRB-

namely

inheritance

polymorphism

and

dynamic

binding

-RRB-

introduce

new

problems

in

software

testing

and

maintenance

Lejter

et

al

-LSB-

-RSB-

also

report

on

the

problems

of

inheritance

and

dynamic

binding

with

respect

to

software

maintenance

Additionally

they

discuss

the

problems

of

attempting

to

answer

questions

such

as

what

is

the

definition

of

this

function

or

where

is

the

declaration

of

this

symbol

without

the

use

of

good

tools

function

and

operator

overloading

they

argue

confuse

such

questions

because

names

are

no

longer

unique

in

object-oriented

systems

Ponder

and

Bush

-LSB-

-RSB-

discuss

the

issue

of

polymorphism

considered

harmful

using

the

Smalltalk

compiler

source

code

listings

as

an

example

polymorphism

causing

understanding

difficulties

While

the

authors

feel

that

it

is

not

necessary

to

know

the

implementations

of

polymorphic

methods

to

understand

their

function

they

report

that

several

problems

arise

first

inferring

the

generic

meaning

of

a

complex

and

obscurely

named

function

from

just

a

few

instances

is

difficult

Second

the

reader

can

inadvertently

be

encouraged

to

infer

similarities

from

different

generic

operations

which

share

the

same

method

name

And

third

the

nature

of

object-oriented

systems

dispersing

operations

across

a

large

number

of

relatively

small

methods

can

make

it

difficult

to

understand

their

collective

effect

Further

polymorphism

they

argue

compounds

this

problem

because

if

a

method

performs

few

operations

there

is

little

basis

for

inferring

the

types

of

its

variables

Ponder

and

Bush

conclude

that

while

polymorphism

can

be

both

a

flexible

and

powerful

programming

tool

it

presents

opportunity

for

abuse

which

can

ruin

program

understanding

Finally

Dvorak

-LSB-

-RSB-

presents

the

property

of

conceptual

entropy

of

class

hierarchies

the

deeper

the

hierarchy

the

more

likely

a

subclass

does

not

consistently

extend

or

specialize

its

parent

's

abstraction

The

concept

was

demonstrated

to

exist

by

an

empirical

study

using

seven

experienced

software

engineers

each

with

on

average

one

years

objectoriented

experience

as

subjects

Dvorak

concluded

that

if

conceptual

entropy

was

left

unchecked

it

would

eventually

reach

a

stage

where

the

class

hierarchy

would

have

to

be

restructured

In

conclusion

there

are

theoretical

arguments

for

the

advantages

of

the

objectoriented

paradigm

but

various

disadvantages

have

been

reported

as

above

In

our

programme

of

research

our

first

step

has

been

to

conduct

structured

interviews

to

explore

these

The

interview

method

The

interview

questions

were

designed

to

elicit

information

on

three

aspects

of

the

users

object-oriented

knowledge

information

on

their

background

e.g.

experience

language

familiarity

their

opinions

on

the

perceived

advantages

and

disadvantages

of

the

paradigm

and

their

opinions

on

existing

object-oriented

technology

e.g.

software

tools

languages

such

as

C++

and

class

libraries

The

interview

was

structured

in

such

a

way

that

factual

questions

-LRB-

requiring

just

one

or

two

sentence

answers

-RRB-

were

asked

first

followed

by

questions

requiring

answers

based

on

opinions

from

experience

This

approach

was

taken

to

allow

the

subject

time

to

settle

and

relax

before

asking

the

more

thought

provoking

questions

A

draft

interview

template

was

written

and

prototyped

by

conducting

an

initial

interview

with

an

experienced

industrial

employee

to

receive

reactions

on

the

structured

interview

technique

and

the

questions

asked

Only

a

minor

point

was

made

and

this

was

then

taken

into

consideration

i.e.

the

subject

felt

not

enough

about

software

tools

was

asked

and

he

stressed

that

tools

were

an

important

part

of

object-oriented

programming

The

draft

template

was

then

revised

to

take

account

of

this

noted

point

the

other

interviews

were

conducted

with

this

refined

template

as

their

basis

Appendix

A

contains

a

copy

of

this

template

Twelve

subjects

all

of

whom

were

individually

approached

agreed

to

be

interviewed

using

the

refined

template

Seven

of

these

subjects

were

industrial

employees

and

five

were

academics

four

of

whom

had

industrial

experience

of

producing

or

working

with

object-oriented

systems

The

subjects

were

given

no

prior

knowledge

of

the

content

of

the

interview

except

that

it

was

based

on

the

object-oriented

paradigm

but

were

told

that

any

replies

given

would

be

treated

confidentially

to

reduce

concern

about

how

their

answers

might

be

used

The

interview

process

was

kept

as

informal

as

possible

e.g.

the

subjects

were

drinking

coffee

before

and

during

the

interview

to

help

them

relax

and

answer

questions

freely

The

interviews

were

carried

out

during

the

working

day

and

lasted

between

minutes

to

almost

hours

The

entire

interview

recorded

using

a

hand

held

recorder

was

transcripted

onto

paper

to

enable

a

thorough

analysis

It

should

be

noted

that

the

initial

interview

was

also

included

in

this

analysis

as

there

was

only

a

minor

difference

between

the

two

templates

used

It

was

hoped

that

the

interview

template

was

comprehensive

but

as

a

safeguard

each

subject

was

asked

the

final

question

Has

there

been

anything

that

you

have

not

been

asked

that

you

feel

is

important

and

should

be

addressed

The

majority

of

subjects

answered

no

to

this

or

mentioned

something

specific

about

their

own

work

which

they

would

have

enjoyed

talking

about

In

all

the

subjects

appeared

to

think

the

interview

was

a

pretty

full

questionnaire

Object-Oriented

Languages

Subject

Pos

Exp

C++

C-Flavours

Eiffel

Objective-C

OO-Pascal

Simula

Smalltalk

A

I

p

p

p

p

B

I

p

C

I

p

p

D

I

p

p

p

E

A

p

F

I

p

G

I

p

p

H

I

p

p

I

A

p

p

p

J

A

p

p

p

K

I

p

p

L

A

p

p

M

A

p

p

p

Table

Subjects

position

experience

-LRB-

years

-RRB-

and

OO

languages

familiarity

Analysis

and

discussion

Analysis

was

undertaken

by

summarizing

each

interview

transcript

and

tabulating

answers

-LRB-

paraphrased

-RRB-

for

each

question

to

compare

and

contrast

them

-LRB-

see

Appendix

B

-RRB-

This

method

of

analysis

has

the

advantage

of

allowing

the

data

to

be

easily

visualized

bearing

in

mind

that

subjects

were

interviewed

Table

summarizes

the

object-oriented

experience

of

the

subjects

their

position

-LRB-

either

an

academic

or

industrialist

-RRB-

and

their

knowledge

of

object-oriented

languages

The

level

of

object-oriented

experience

varied

from

months

to

years

but

note

that

the

least

experienced

used

it

every

working

day

So

we

feel

justified

in

describing

all

these

subjects

as

experienced

object-oriented

users

-LRB-

only

I

J

and

L

were

not

daily

users

-RRB-

Learning

curve

documentation

time

pressures

and

quick

fixes

First

several

subjects

mentioned

the

learning

curve

as

an

influencing

feature

when

changing

from

the

structured

design

paradigm

to

that

of

object-orientation

Subjects

A

I

J

and

L

made

the

point

that

the

learning

curve

was

steep

Additionally

subject

J

commented

you

really

have

to

think

differently

I

'm

still

thinking

in

structured

C

in

some

ways

-LRB-

repeating

the

point

made

in

-LSB-

-RSB-

-RRB-

and

subject

L

reckoned

to

fully

make

the

transition

can

take

as

much

as

two

years

Regarding

the

transition

from

structured

to

object-oriented

programming

subjects

B

K

L

and

M

said

the

use

of

hybrid

languages

e.g.

C++

has

a

detrimental

influence

while

C++

allows

the

programmer

to

write

C

code

providing

several

advantages

e.g.

use

of

existing

C

libraries

familiarity

with

C

and

not

all

problems

are

suited

to

an

object-oriented

solution

according

to

subject

K

it

's

a

language

which

does

n't

really

encourage

to

think

in

terms

of

objects

-LRB-

subjects

B

L

and

M

agreed

-RRB-

Consequently

according

to

subject

B

someone

might

just

regress

into

doing

something

in

a

C

fashion

when

they

should

be

doing

it

in

an

object-oriented

fashion

Subject

M

said

being

forced

to

be

object-oriented

I

'm

sure

actually

helped

me

Lozinski

-LSB-

-RSB-

details

many

of

the

limitations

of

C++

and

provides

some

excellent

accompanying

discussion

by

comparing

it

to

Objective-C

-LRB-

Tables

and

provide

individual

comments

-RRB-

Second

ten

subjects

including

all

industrial

subjects

mentioned

that

they

had

had

trouble

with

the

availability

of

design

documentation

either

it

did

not

exist

or

it

was

inadequate

Additionally

subject

K

mentioned

when

time

constraints

become

a

factor

documentation

is

the

first

thing

that

suffers

-LRB-

subjects

A

and

D

made

similar

statements

-RRB-

Moreover

subject

L

mentioned

that

documentation

for

object-oriented

systems

is

a

more

important

aid

to

understanding

than

it

is

for

other

systems

Subject

G

qualified

design

documentation

is

important

otherwise

you

are

back

to

where

you

were

before

-LSB-

with

structured

designed

systems

-RSB-

The

subject

made

the

point

that

object-oriented

systems

are

not

easier

to

understand

than

other

systems

unless

the

design

documentation

fully

captures

class

relationships

class

member

functions

member

variables

and

so

on

Subject

M

supported

this

claiming

documentation

is

essential

However

according

to

subject

H

on

the

last

project

I

worked

on

there

was

n't

any

decent

documentation

anyway

you

might

find

that

that

's

by

far

the

most

common

case

that

there

's

no

good

up

to

date

design

documentation

-LRB-

Tables

and

provide

individual

comments

-RRB-

Third

eleven

subjects

thought

it

was

possible

to

perform

quick

fixes

on

objectoriented

code

e.g.

yes

particularly

in

C++

it

's

too

easy

in

C++

in

C++

it

's

a

lot

easier

it

's

all

too

easy

it

's

really

easy

and

the

temptation

is

always

there

Subject

L

qualified

this

as

one

of

the

dangers

in

these

hybrid

languages

while

subject

G

stated

yes

but

that

's

bad

maintenance

rather

than

bad

design

Subjects

A

C

D

F

and

K

mentioned

a

quick

fix

can

be

the

result

of

time

pressures

In

a

previous

paper

-LSB-

-RSB-

the

authors

have

discovered

pragmatic

maintenance

-LRB-

performing

the

minimal

amount

possible

to

complete

the

required

task

-RRB-

under

controlled

laboratory

conditions

-LRB-

Tables

and

provide

individual

comments

-RRB-

The

problems

mentioned

above

appear

indicative

of

Kung

et

al

's

-LSB-

-RSB-

experience

who

state

Our

experience

indicates

that

it

is

extremely

time

consuming

and

tedious

to

test

and

maintain

an

OO

software

system

This

becomes

even

more

acute

when

documentation

is

either

missing

or

inadequate

Inheritance

and

high

level

understanding

First

subjects

A

C

F

G

I

and

L

made

the

point

that

if

inheritance

is

designed

properly

-LRB-

the

hierarchy

is

structured

using

the

appropriate

abstractions

-RRB-

then

it

will

not

cause

understanding

difficulties

Additionally

of

these

subjects

agreed

that

if

designed

properly

inheritance

should

aid

understanding

On

the

other

hand

subjects

D

E

H

J

K

and

M

mentioned

that

inheritance

can

make

understanding

difficult

subject

D

said

that

it

can

be

difficult

to

trace

the

flow

of

control

while

subjects

J

K

and

M

mentioned

that

tracing

a

line

of

method

invocations

to

determine

which

method

is

performing

the

work

is

difficult

-LRB-

repeating

two

of

the

points

in

-LSB-

-RSB-

-RRB-

Subjects

H

and

K

agreed

it

can

be

difficult

to

understand

what

functionality

a

line

of

code

is

performing

until

it

is

realised

it

calls

an

inherited

member

function

Subjects

H

and

K

also

agreed

inheritance

can

cause

confusion

when

interacting

with

inherited

member

variables

where

have

they

been

inherited

from

-LRB-

repeating

two

of

the

points

in

-LSB-

-RSB-

-RRB-

However

subject

C

's

statement

made

in

the

context

of

design

appears

to

best

fit

the

general

opinion

I

think

on

the

whole

it

comes

back

slightly

to

how

well

written

the

code

is

I

think

once

you

get

into

the

way

of

thinking

about

inheritance

it

does

not

make

it

more

difficult

to

understand

and

in

fact

often

makes

it

a

lot

simpler

and

if

your

code

is

badly

written

then

it

's

a

nightmare

-LRB-

Table

provides

individual

comments

-RRB-

Second

regarding

the

effect

of

spreading

method

functionality

over

the

inheritance

hierarchy

on

system

understanding

almost

every

subject

commented

that

if

the

inheritance

hierarchy

is

designed

properly

then

it

would

not

be

detrimental

to

understanding

Additionally

subject

A

said

that

it

was

a

natural

way

of

writing

and

understanding

code

subject

C

declared

that

it

's

likely

to

aid

understanding

and

subject

H

stated

it

simplifies

things

it

simplifies

your

design

-LRB-

Table

provides

individual

comments

-RRB-

Third

an

issue

discussed

was

the

depth

of

inheritance

and

how

it

affects

system

understanding

Subjects

were

asked

to

define

how

many

levels

of

inheritance

it

took

before

their

understanding

began

to

become

constrained

These

definitions

are

summarised

in

Table

Subject

C

said

that

levels

of

inheritance

-LRB-

including

multiple

inheritance

-RRB-

would

be

a

deep

and

complex

hierarchy

The

subject

added

that

Depth

of

inheritance

-LRB-

levels

-RRB-

Subject

Not

relevant

A

p

B

p

C

p

MI

D

p

E

p

F

p

G

p

H

p

I

p

J

p

K

p

MI

L

M

p

Table

Subject

opinions

on

a

deep

inheritance

hierarchy

you

want

to

avoid

using

a

depth

of

nesting

that

you

do

n't

need

and

it

's

therefore

inappropriate

The

subject

made

the

point

that

the

hierarchy

must

be

properly

designed

Subject

H

also

noted

that

levels

of

inheritance

is

a

deep

hierarchy

In

contrast

subject

I

stated

that

depth

was

not

an

issue

he

ever

considered

and

therefore

the

question

was

not

relevant

The

remaining

subjects

mainly

noted

levels

of

inheritance

as

deep

Comparison

of

Tables

and

shows

no

significant

relationship

between

experience

or

the

language

and

the

depth

of

inheritance

Fourth

subjects

B

C

G

H

I

and

K

mentioned

that

multiple

inheritance

is

more

complex

than

single

inheritance

Additionally

subject

L

was

concerned

that

multiple

inheritance

allowed

for

a

sloppy

approach

-LRB-

inappropriate

inheritance

-RRB-

He

stated

his

reluctance

to

use

multiple

inheritance

by

mentioning

anything

designed

using

multiple

inheritance

can

be

designed

using

single

inheritance

Subjects

B

and

H

agreed

mentioning

that

multiple

inheritance

makes

your

design

more

complex

On

the

other

hand

subjects

C

E

and

K

stated

multiple

inheritance

had

benefits

Subject

C

reckoned

it

is

easier

to

reuse

with

multiple

inheritance

and

it

can

also

make

maintenance

changes

easier

Subject

E

mentioned

it

maps

the

reality

of

systems

being

modelled

and

subject

K

agreed

reporting

that

if

you

have

a

real

case

for

multiple

inheritance

then

it

is

advantageous

to

use

it

Subjects

B

G

and

L

disagreed

however

Both

B

and

L

stated

multiple

inheritance

is

more

tightly

coupled

than

single

and

therefore

reuse

it

harder

most

subjects

talked

in

the

context

of

C++

for

the

majority

of

the

interview

Inheritance

Advantages

Disadvantages

Allows

design

at

the

highest

level

of

abstraction

Understanding

is

difficult

if

not

well

designed

Provides

modularity

Overuse

or

inappropriate

use

of

inheritance

leads

Prevents

code

redundancy

to

more

complex

code

that

's

harder

to

follow

Aid

to

understanding

if

designed

well

Multiple

inheritance

can

complicate

the

design

Information

hiding

through

encapsulation

Tracing

flow

of

control

and

dependencies

can

be

Quick

prototyping

difficult

Single

inheritance

encourages

good

design

New

concept

to

learn

Multiple

inheritance

for

complex

designs

Deep

hierarchies

can

cause

understanding

difficulties

Table

Summary

of

inheritance

advantages

and

disadvantages

while

subject

G

stated

single

inheritance

is

the

way

to

do

it

-LRB-

Table

provides

individual

comments

-RRB-

Finally

Table

summarizes

the

discussed

advantages

and

disadvantages

of

inheritance

-LRB-

Tables

and

provide

individual

comments

-RRB-

Maintenance

of

object-oriented

programs

First

regarding

the

effect

of

making

changes

to

object-oriented

programs

in

comparison

to

equivalent

structured

programs

subjects

A

B

C

D

E

F

G

H

K

and

L

stressed

that

if

well

designed

changes

are

made

to

a

well

designed

object-oriented

system

the

effects

of

these

changes

are

likely

to

be

more

localized

with

object-oriented

code

than

with

structured

code

In

contrast

if

the

changes

are

not

well

designed

changes

then

they

are

just

as

likely

to

propagate

through

an

object-oriented

system

as

much

as

any

other

Although

subjects

D

H

J

and

K

agreed

that

changes

are

more

localized

in

an

objectoriented

system

these

subjects

also

noted

that

changes

can

also

have

a

bigger

global

effect

because

any

changes

made

will

affect

subclasses

which

inherit

them

-LRB-

repeating

the

point

in

-LSB-

-RSB-

and

-LSB-

-RSB-

-RRB-

On

the

other

hand

subjects

D

H

and

K

noted

that

this

concept

has

the

benefit

of

being

able

to

fix

it

for

one

fix

it

for

all

if

class

X

has

a

corrective

maintenance

change

made

then

any

subclass

Y

has

that

change

made

automatically

through

inheritance

-LRB-

a

benefit

not

mentioned

in

-LSB-

-RSB-

or

-LSB-

-RSB-

-RRB-

Subjects

B

D

G

J

and

L

raised

the

issue

of

tracing

of

method

dependencies

through

the

class

hierarchy

as

problematic

-LRB-

repeating

the

points

in

-LSB-

-RSB-

and

-LSB-

-RSB-

-RRB-

According

to

subject

K

just

seeing

where

a

piece

of

code

does

that

work

from

the

point

of

view

of

understandability

can

be

quite

tricky

The

subjects

agreed

this

is

compounded

when

the

hierarchy

is

deep

-LRB-

Tables

and

provide

individual

comments

-RRB-

Second

regarding

object-oriented

programs

causing

problems

for

software

maintainers

Subject

A

related

it

to

the

learning

curve

understanding

the

way

an

object-oriented

program

works

is

not

easy

to

begin

with

and

takes

time

to

acquire

the

correct

method

of

thinking

learning

by

osmosis

-LRB-

repeating

the

point

made

in

-LSB-

-RSB-

-RRB-

Subject

J

repeated

that

missing

documentation

could

cause

maintainers

difficulty

Subjects

B

and

K

mentioned

the

one

class

per

file

style

promoted

by

Stroustrup

-LSB-

-RSB-

as

undesirable

it

can

make

tracing

of

dependencies

extremely

difficult

without

good

tool

support

-LRB-

repeating

the

point

in

-LSB-

-RSB-

-RRB-

The

general

opinion

was

however

that

there

is

more

structure

to

a

well

designed

object-oriented

system

and

as

such

it

is

easier

to

maintain

than

a

non

object-oriented

system

although

subject

L

felt

that

few

object-oriented

systems

have

had

sufficient

maintenance

to

be

able

to

say

-LRB-

Tables

and

provide

individual

comments

-RRB-

Third

subjects

were

asked

if

they

thought

that

continual

maintenance

would

eventually

lead

to

unmaintainability

The

majority

of

subjects

commented

that

this

would

be

the

case

although

in

comparison

to

an

equivalent

structured

program

there

is

a

lesser

tendency

for

this

to

happen

i.e.

it

would

still

happen

but

over

a

longer

of

period

time

Subject

A

stated

this

would

happen

without

a

doubt

the

rate

of

entropy

increases

over

time

and

everything

tends

to

disorder

Subject

D

also

discussed

the

rate

of

entropy

and

conceded

it

is

reduced

for

object-oriented

systems

Subject

E

agreed

but

only

on

the

condition

that

programmers

maintain

the

object

mindset

for

making

changes

to

the

system

Subject

J

made

a

similar

statement

Subject

H

concluded

that

as

with

anything

if

ad

hoc

changes

are

made

then

unmaintainability

will

ensue

-LRB-

Table

provides

individual

comments

-RRB-

Fourth

subjects

mentioned

that

tools

are

helpful

for

understanding

and

maintaining

object-oriented

programs

Differences

of

opinion

did

arise

about

whether

they

are

a

necessity

or

not

subjects

E

F

H

J

K

L

and

M

all

declaring

they

are

the

remainder

declaring

they

are

not

All

the

subjects

however

did

agree

that

tools

do

alleviate

some

of

the

understanding

problems

that

can

occur

when

performing

object-oriented

software

maintenance

Subject

I

reckoned

that

more

object-oriented

tools

are

needed

-LRB-

Table

provides

individual

comments

-RRB-

Finally

subjects

A

B

C

D

G

K

and

M

mentioned

that

it

would

be

difficult

for

a

maintainer

to

tell

if

any

changes

made

had

degraded

the

system

code

quality

-LRB-

repeating

the

point

made

in

-LSB-

-RSB-

-RRB-

Code

reviews

and

walk-throughs

performed

by

a

panel

of

programmers

are

recommended

practice

by

these

subjects

as

a

reliable

safety

net

for

catching

any

introduced

bugs

-LRB-

Table

provides

individual

comments

-RRB-

Other

issues

First

regarding

small

methods

as

good

object-oriented

programming

practice

subject

A

concluded

that

methods

can

be

one

line

but

as

much

as

lines

for

real

methods

depending

on

their

function

Subject

F

stated

I

try

to

keep

them

small

However

subjects

B

C

D

and

K

all

mentioned

methods

of

size

in

excess

of

lines

of

code

-LRB-

subject

C

had

worked

with

a

method

of

lines

-RRB-

although

this

was

not

regarded

as

good

programming

practice

In

general

the

subjects

felt

that

small

methods

are

good

programming

practice

-LRB-

Table

provides

individual

comments

-RRB-

Second

subjects

were

asked

if

they

had

ideas

on

good

and

bad

object-oriented

programming

practices

Once

more

the

importance

of

design

was

stressed

Subjects

A

C

F

I

K

and

M

mentioned

that

good

design

usually

means

good

code

conversely

bad

design

produces

bad

code

According

to

subject

C

it

is

almost

less

the

coding

style

than

the

design

style

that

is

important

Additionally

subjects

C

and

D

agreed

that

not

too

deep

an

inheritance

tree

was

good

style

-LRB-

although

from

Table

it

can

be

seen

their

definitions

of

deep

differ

-RRB-

Subject

H

added

there

seems

to

be

few

points

of

reference

for

object-oriented

code

quality

The

rules

and

recommendations

produced

by

Henricson

and

Nyquist

-LSB-

-RSB-

is

one

programming

standard

for

object-oriented

programming

which

may

help

to

reduce

any

inconsistencies

that

exist

-LRB-

Table

provides

individual

comments

-RRB-

Third

every

subject

interviewed

thought

that

polymorphism

is

a

useful

concept

in

object-oriented

programming

and

they

agreed

it

can

produce

generic

code

However

subjects

B

C

E

G

I

and

J

mentioned

that

polymorphism

especially

if

semantic

consistency

is

not

maintained

can

cause

confusion

and

make

it

difficult

to

understand

how

the

system

works

In

particular

subject

B

stated

Yes

it

's

a

great

benefit

in

some

cases

In

some

cases

it

makes

things

really

difficult

to

understand

Used

properly

and

used

reasonably

sparingly

it

can

be

really

advantageous

-LRB-

This

reiterates

the

conclusions

drawn

in

-LSB-

-RSB-

-RRB-

-LRB-

Tables

and

provide

individual

comments

-RRB-

Similarly

regarding

dynamic

binding

while

every

subject

thought

that

it

a

clearly

defined

benefit

-LRB-

subject

A

remarked

without

it

there

is

no

object-oriented

programming

-RRB-

subjects

C

E

L

and

M

felt

that

there

can

be

understanding

difficulties

if

the

programmer

was

careless

when

using

it

Subjects

C

and

L

mentioned

that

one

of

the

big

problems

is

the

calling

of

non-existent

methods

However

if

managed

carefully

then

according

to

subject

D

it

simplifies

the

code

It

's

a

more

intuitive

way

of

working

-LRB-

these

points

do

not

directly

support

the

points

made

in

-LSB-

-RSB-

or

-LSB-

-RSB-

-RRB-

-LRB-

Table

provides

individual

comments

-RRB-

Fourth

regarding

software

reuse

only

subject

E

had

not

made

any

use

of

class

libraries

The

remaining

subjects

all

made

use

of

commercially

produced

libraries

however

subjects

A

D

I

K

and

L

were

the

only

frequent

users

of

local

class

libraries

No

generalization

can

be

made

but

it

does

support

asking

the

question

is

object-orientation

meeting

its

reputation

for

ease

of

software

reuse

-LRB-

Tables

and

provide

individual

comments

-RRB-

Finally

subjects

were

asked

to

complete

the

interview

with

a

conclusion

on

the

utility

of

the

object-oriented

paradigm

-LRB-

is

it

beneficial

-RRB-

Every

subject

answered

yes

for

example

no

doubt

about

it

the

only

way

the

right

thing

to

do

where

it

's

appropriate

it

's

the

way

forward

Again

no

generalization

can

be

made

but

it

does

deserve

recognition

as

of

some

importance

Conclusions

and

future

work

Interviewing

users

on

the

advantages

and

disadvantages

of

aspects

of

software

engineering

can

be

rewarding

it

can

help

to

identify

-LRB-

i

-RRB-

problems

not

yet

considered

-LRB-

ii

-RRB-

conditions

under

which

existing

problems

are

compounded

or

alleviated

or

not

applicable

and

-LRB-

iii

-RRB-

claims

which

appear

worthy

of

further

empirical

inquiry

and

those

that

do

not

Furthermore

the

structured

interview

can

be

an

effective

method

of

exploratory

or

primary

investigation

when

undertaking

a

multi-method

programme

of

empirical

research

We

warn

however

against

generalising

the

results

of

this

study

due

to

its

limited

sample

size

It

is

believed

that

the

weaknesses

of

the

structured

interview

technique

were

not

a

major

influence

on

this

study

because

-LRB-

a

-RRB-

anonymity

of

subjects

and

the

interview

setting

encouraged

them

to

speak

freely

-LRB-

b

-RRB-

the

interviewer

's

experience

in

the

domain

meant

further

investigation

of

important

points

and

-LRB-

c

-RRB-

clarification

of

elicitated

knowledge

could

be

made

after

the

interview

transcript

was

available

The

analysis

was

performed

by

transcripting

and

summarizing

each

interview

and

tabulating

subjects

answers

to

each

question

Interview

transcripts

were

read

several

times

and

it

is

unlikely

that

any

important

points

were

overlooked

Analysis

of

the

collected

interview

data

uncovered

several

aspects

of

marked

interest

First

the

learning

curve

was

mentioned

as

being

steep

when

switching

to

the

objectoriented

paradigm

from

another

different

paradigm

the

figure

of

almost

two

years

was

mentioned

to

make

the

transition

Second

depth

of

inheritance

was

discussed

excessive

inheritance

depth

or

inappropriate

use

of

inheritance

can

cause

understanding

difficulties

and

is

therefore

something

to

be

avoided

-LRB-

any

initial

time

saved

will

be

outweighed

by

the

difficulties

the

inappropriate

inheritance

causes

-RRB-

In

contrast

inheritance

when

designed

and

implemented

appropriately

is

more

likely

to

aid

understanding

than

compound

it

Understanding

difficulties

are

created

by

dependencies

caused

by

inheritance

however

Tracing

a

line

of

dependencies

through

inheritance

hierarchies

to

find

where

the

work

is

being

performed

can

be

a

time-consuming

task

Third

object-oriented

systems

are

as

prone

if

not

more

so

to

the

problems

of

missing

documentation

Several

subjects

mentioned

that

time

constraints

can

cause

documentation

to

suffer

The

drawbacks

of

missing

documentation

should

be

considered

carefully

from

a

maintenance

perspective

If

the

documentation

captures

the

correct

information

it

could

reduce

future

time

pressures

subsequent

changes

may

be

properly

designed

reducing

system

degradation

if

not

then

the

reverse

might

be

true

Fourth

the

design

of

an

object-oriented

system

appears

to

be

extremely

important

subjects

continually

mentioned

design

when

discussing

the

problems

of

inheritance

software

maintenance

polymorphism

and

dynamic

binding

stating

that

if

the

design

was

appropriate

then

understanding

was

not

constrained

In

contrast

however

if

not

well

designed

then

the

system

could

be

a

nightmare

to

understand

Fifth

as

a

consequence

of

software

maintenance

object-oriented

systems

are

still

prone

to

degradation

The

consensus

however

was

that

object-oriented

software

would

resist

software

degradation

through

maintenance

better

than

other

software

systems

but

only

if

the

object

mindset

is

kept

when

performing

maintenance

quick

fixes

are

likely

to

increase

software

degradation

-LRB-

or

the

rate

of

entropy

as

referred

to

by

subjects

-RRB-

to

that

of

any

other

software

Trainees

therefore

are

not

the

best

people

to

perform

maintenance

Finally

subjects

indicated

a

lack

of

enthusiasm

towards

C++

and

viewed

it

inferior

in

many

aspects

to

purer

object-oriented

languages

Finally

as

discussed

in

the

introduction

a

programme

of

research

using

different

empirical

techniques

is

more

likely

to

allow

conclusions

which

hold

weight

if

an

effect

has

been

consistently

demonstrated

Conducting

the

structured

interviews

was

the

first

technique

in

our

planned

multi-method

approach

The

next

stage

in

this

research

was

designing

a

questionnaire

from

the

structured

interview

findings

to

gather

quantitative

data

on

a

wider

user

group

Analysis

of

this

survey

data

is

currently

being

undertaken

Acknowledgments

Thanks

must

be

extended

to

those

who

agreed

to

be

interviewed

Thanks

are

also

given

to

Mrs

Fiona

Ferguson

Smith

who

helped

with

the

interview

transcripts

Finally

thanks

go

to

Dr

Kevin

Waite

who

helped

organise

the

interview

sessions

and

provided

feedback

on

an

earlier

draft

of

this

document

References

-LSB-

-RSB-

L

Bainbridge

Verbal

protocol

analysis

In

J

Wilson

and

E

Corlett

editors

Evaluation

of

Human

Work

A

practical

ergonomics

methodology

pages

-LCB-

Taylor

and

Francis

-LSB-

-RSB-

A

Brooks

J

Daly

J

Miller

M

Roper

and

M

Wood

Replication

of

experimental

results

in

software

engineering

submitted

to

IEEE

Transactions

on

Software

Engineering

-LSB-

-RSB-

H

Collins

CHANGING

ORDER

Replication

and

Induction

in

Scientific

Practice

SAGE

Publications

-LSB-

-RSB-

J

Daly

A

Brooks

J

Miller

M

Roper

and

M

Wood

Verification

of

results

in

software

maintenance

through

external

replication

In

Proceedings

of

the

IEEE

International

Conference

on

Software

Maintenance

pages

-LCB-

September

-LSB-

-RSB-

S

Denning

D

Hoiem

M

Simpson

and

K

Sullivan

The

value

of

thinking

aloud

protocols

in

industry

A

case

study

at

Microsoft

Corporation

In

Proceedings

of

the

Human

Factors

Society

Annual

Meeting

pages

-LCB-

-LSB-

-RSB-

J

Dvorak

Conceptual

entropy

and

its

effect

on

class

hierarchies

IEEE

Computer

-LRB-

-RRB-

-LCB-

June

-LSB-

-RSB-

A

Ericsson

and

H

Simon

Protocol

Analysis

The

MIT

Press

edition

-LSB-

-RSB-

N

Fenton

S

Pfleeger

and

R

Glass

Science

and

substance

A

challenge

to

software

engineers

IEEE

Software

-LRB-

-RRB-

-LCB-

July

-LSB-

-RSB-

J

Goguen

and

C

Linde

Techniques

for

requirements

elicitation

In

Proceedings

of

the

IEEE

International

Symposium

on

Requirements

Engineering

pages

-LCB-

-LSB-

-RSB-

M

Henricson

and

E

Nyquist

Programming

in

C++

Rules

and

Recommendations

Ellemtel

Telecommunications

Systems

Laboratories

-LSB-

-RSB-

S

Henry

M

Humphrey

and

J

Lewis

Evaluation

of

the

maintainability

of

object

oriented

software

In

IEEE

Region

Conference

on

Computer

and

Communication

Systems

pages

-LCB-

September

-LSB-

-RSB-

C

Jones

Gaps

in

the

object-oriented

paradigm

IEEE

Computer

-LRB-

-RRB-

-LCB-

June

-LSB-

-RSB-

D

Kung

J

Gao

P

Hsia

F

Wen

Y

Toyoshima

and

C

Chen

Change

impact

identification

in

object-oriented

software

maintenance

In

Proceedings

of

the

IEEE

International

Conference

on

Software

Maintenance

pages

-LCB-

September

-LSB-

-RSB-

M

Lejter

S

Meyers

and

S

Reiss

Support

for

maintaining

object-oriented

programs

IEEE

Transactions

on

Software

Engineering

-LRB-

-RRB-

-LCB-

December

-LSB-

-RSB-

C

Lozinski

Why

I

need

Objective-C

Journal

of

Object-Oriented

Programming

pages

-LCB-

September

-LSB-

-RSB-

D

Mancl

and

W

Havanas

A

study

of

the

impact

of

C++

on

software

maintenance

In

Proceedings

of

the

IEEE

Conference

on

Software

Maintenance

pages

-LCB-

-LSB-

-RSB-

G

Marchionini

Evaluating

hypermedia-based

learning

In

D

Jonassen

and

H

Mandel

editors

Designing

hypertext/hypermedia

for

learning

pages

-LCB-

Springer-Verlag

-LSB-

-RSB-

J

Neilson

Evaluating

the

thinking-aloud

technique

for

use

by

computer

scientists

In

R

Hartson

editor

Advances

in

Human

Computer

Interaction

volume

pages

-LCB-

Ablex

Publishing

Corporation

-LSB-

-RSB-

C

Ponder

and

B

Bush

Polymorphism

considered

harmful

ACM

SIGSOFT

Software

Engineering

Notes

-LRB-

-RRB-

-LCB-

April

-LSB-

-RSB-

N

Shadbolt

and

M

Burton

Knowledge

elicitation

In

J

Wilson

and

E

Corlett

editors

Evaluation

of

Human

Work

A

practical

ergonomics

methodology

pages

-LCB-

Taylor

and

Francis

-LSB-

-RSB-

M

Sinclair

Subjective

assessment

In

J

Wilson

and

E

Corlett

editors

Evaluation

of

Human

Work

A

practical

ergonomics

methodology

pages

-LCB-

Taylor

and

Francis

-LSB-

-RSB-

B

Stroustrup

The

C++

Programming

Language

Addison-Wesley

edition

-LSB-

-RSB-

D

Walz

J

Elam

and

B

Curtis

Inside

a

software

design

team

Knowledge

acquisition

sharing

and

integration

Communications

of

the

ACM

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

N

Wilde

and

R

Huitt

Maintenance

support

for

object-oriented

programs

IEEE

Transactions

on

Software

Engineering

-LRB-

-RRB-

-LCB-

December

-LSB-

-RSB-

N

Wilde

P

Mathews

and

R

Huitt

Maintaining

object-oriented

software

IEEE

Software

-LRB-

-RRB-

-LCB-

A

Interview

template

Introduction

Thanks

for

taking

the

time

to

be

interviewed

on

this

subject

The

questions

I

'll

ask

will

start

off

as

relatively

simple

and

should

mainly

be

one

or

two

sentence

answers

Later

questions

move

into

more

complicated

areas

and

will

mainly

ask

for

opinions

gained

from

actual

experience

reading

and/or

conferring

with

your

colleagues

To

what

extent

is

your

knowledge

of

object-oriented

programming

that

is

how

long

have

you

used

it

and

how

often

do

you

use

it

Which

language

or

languages

are

you

most

familiar

with

What

size

in

executable

lines

of

code

are

on

average

a

single

object

's

method

-LRB-

you

may

give

a

range

if

you

wish

-RRB-

Compared

to

structured

programs

what

would

you

say

the

effect

of

changes

are

in

object-oriented

programs

For

example

are

changes

likely

to

cause

ripples

to

propagate

through

the

system

or

be

localised

to

particular

objects

Do

you

use

the

inheritance

facilities

of

your

language

-LRB-

s

-RRB-

No

why

not

Yes

how

often

Do

you

think

inheritance

can

cause

difficulties

when

-LRB-

a

-RRB-

trying

to

understand

the

code

as

a

whole

-LRB-

b

-RRB-

trying

to

understanding

small

segments

of

code

-LRB-

eg

as

a

s/w

maintenance

engineer

might

do

-RRB-

No

what

about

when

the

inheritance

hierarchy

is

particularly

deep

No

why

not

Yes

see

next

question

Yes

As

a

consequence

do

you

think

that

software

tools

are

a

necessity

for

understanding

and

maintaining

object-oriented

programs

No

why

not

Yes

Why

Any

particular

types

you

find

useful

e.g.

a

cross

reference

browser

etc

Inheritance

can

spread

the

functionality

of

particular

methods

over

the

system

What

do

you

think

is

the

impact

of

this

from

an

understanding

point

of

view

What

do

you

think

is

the

impact

of

this

from

a

maintenance

point

of

view

What

benefits

except

for

reuse

do

you

think

inheritance

provides

What

disadvantages

do

you

think

inheritance

introduces

-LRB-

apart

from

the

ones

already

discussed

-RRB-

The

argument

of

inheritance

versus

multiple

inheritance

has

existed

for

some

time

now

What

are

your

opinions

on

this

discussion

Which

option

do

you

think

is

best

Without

discussing

inheritance

can

object-oriented

code

in

your

opinion

cause

problems

to

software

maintenance

engineers

Yes

Expand

on

these

problems

No

What

makes

it

easy

to

maintain

then

It

is

possible

to

maintain

imperative

code

to

death

that

is

the

quality

of

the

code

deteriorates

as

it

is

continually

maintained

until

it

becomes

unmaintainable

Do

you

think

that

this

can

happen

to

object-oriented

code

given

changes

are

performed

in

an

object

oriented

fashion

No

why

not

Yes

why

How

much

use

do

you

make

of

the

class

libraries

which

language

Do

you

ever

maintain

these

libraries

by

updating

them

No

why

not

Yes

What

is

the

procedure

for

this

Do

you

think

as

class

libraries

increase

in

size

and

are

used

more

often

the

maintenance

overhead

spent

on

them

will

be

greater

than

the

maintenance

overhead

of

the

actual

product

Do

you

have

any

opinions

on

what

is

good

or

bad

programming

style

when

concerned

with

object-oriented

code

quality

Has

your

company

produced

guidelines

you

should

adhere

to

Given

that

a

software

maintenance

engineer

makes

changes

on

a

small

scale

for

example

modifying

a

method

or

adding

a

new

method

is

it

possible

to

know

whether

the

changes

made

have

degraded

the

system

code

quality

Would

in

your

opinion

a

software

maintenance

engineer

consult

any

design

documentation

to

help

him/her

understand

specific

pieces

of

code

causing

difficulty

Do

you

think

that

dynamic

binding

causes

more

problems

than

advantages

Yes

Expand

on

the

specific

disadvantages

you

feel

are

the

worst

No

Expand

on

the

specific

advantages

you

feel

are

the

best

Polymorphism

has

been

said

to

be

a

great

strength

of

oo

languages

but

is

also

said

to

introduce

difficulties

in

program

analysis

and

understanding

Would

you

agree

with

this

statement

Yes

Why

No

Why

not

Polymorphism

however

requires

consistent

use

of

method

names

within

a

system

Have

you

experienced

any

particular

problems

with

consistent

naming

in

this

manner

What

about

the

case

of

operator

overloading

Yes

What

kind

of

problems

No

Why

is

this

Are

you

aware

of

the

C++

language

Yes

What

do

you

feel

are

the

disadvantages

of

this

language

when

compared

to

other

object-oriented

languages

What

advantages

does

C++

hold

over

other

OO

languages

No

nothing

further

When

a

software

maintenance

engineer

makes

modifications

is

it

possible

that

he

might

hack

in

a

quick

fix

instead

of

trying

to

maintain

object-orientedness

Yes

Have

you

done

this

yourself

Have

seen

this

done

by

any

of

your

colleagues

Why

is

this

quicker

No

Why

not

To

conclude

do

you

believe

that

the

object-oriented

paradigm

taking

everything

into

consideration

is

beneficial

Has

there

been

anything

that

you

have

not

been

asked

that

you

feel

is

important

and

should

be

addressed

or

anything

you

would

like

to

reiterate

B

Subject

responses

This

section

details

a

summary

of

the

remarks

that

individual

subjects

made

to

specific

questions

and

issues

The

data

are

presented

in

paraphrased

form

-LRB-

although

quotes

indicates

the

subjects

own

words

-RRB-

No

mention

of

a

subject

's

response

means

that

nothing

significant

was

mentioned

Tables

are

ordered

by

interview

template

questions

-LRB-

Appendix

A

-RRB-

Remarks

made

by

a

subject

related

to

a

topic

but

not

given

directly

to

the

specific

question

are

indicated

and

are

tabulated

in

the

appropriate

table

Subject

Remark

A

Small

but

up

to

B

C

-LRB-

C-Flavours

-RRB-

D

E

F

keep

them

small

G

H

I

J

lines

K

L

lines

M

screenful

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

Changes

are

localized

but

hard

to

tell

if

system

quality

is

degraded

Good

design

is

the

key

B

Depends

on

the

design

changes

localized

if

good

design

but

will

affect

the

whole

system

if

not

C

It

depends

on

how

well

written

and

designed

they

are

less

implications

if

this

is

done

well

but

difficult

to

maintain

otherwise

D

Must

be

well

designed

if

they

are

then

changes

more

localized

E

Localized

but

design

very

important

F

Design

very

important

have

classes

correct

-LRB-

good

abstractions

-RRB-

then

more

localized

G

Well

designed

code

then

changes

are

localized

bad

code

then

they

're

not

H

Good

design

important

if

good

design

then

changes

more

localized

I

More

modular

code

with

object-orientation

and

less

like

to

require

changes

J

Localized

but

can

have

a

bigger

global

effect

affect

all

subclasses

K

More

localized

design

important

L

Localized

again

design

is

important

M

Objects

are

structured

pieces

of

code

more

adaptable

to

change

and

easier

to

maintain

Table

Answers

and

remarks

to

Q.

and

various

other

questions

Subject

Remark

A

Tools

are

useful

but

not

a

necessity

class

browser

B

Not

a

necessity

if

you

do

n't

need

tools

to

understand

a

non

OO

program

then

you

do

n't

need

them

for

an

OO

program

C

Not

a

necessity

but

useful

D

Not

a

necessity

but

very

helpful

E

Yes

a

necessity

you

need

them

for

visibility

of

whole

maintenance

process

F

Yes

a

necessity

but

that

's

the

case

with

everything

G

Not

a

necessity

but

a

definite

benefit

H

Yes

a

necessity

it

's

hard

to

know

the

relationships

between

classes

without

them

I

Tools

are

very

important

more

are

needed

J

I

think

they

are

a

necessity

if

dealing

with

something

big

then

yes

K

A

necessity

they

help

to

visualize

things

you

might

not

have

realised

L

A

necessity

yes

I

think

so

M

A

necessity

a

good

browser

is

essential

Table

Answers

and

remarks

from

Q.

Subject

Remark

A

Makes

it

easier

if

abstractions

are

designed

and

implemented

properly

B

It

should

n't

make

understanding

difficult

inherited

classes

should

implement

same

sort

of

function

understand

the

base

class

method

to

know

what

it

's

doing

C

Inheritance

makes

understanding

easier

but

it

must

be

well

designed

and

well

written

D

Inheritance

causes

difficulties

for

tracing

the

flow

of

control

particularly

with

multiple

inheritance

you

do

n't

know

where

you

are

going

to

end

up

E

Yes

without

fully

appreciating

repercussions

in

terms

of

dynamics

F

Yes

but

only

if

it

's

wrong

if

the

inheritance

is

inappropriate

G

It

means

tracing

through

more

code

but

if

done

well

then

no

problems

H

It

can

when

methods

are

overloaded

e.g.

where

does

this

member

variable

get

inherited

is

hard

to

answer

I

No

difficulty

ca

n't

see

why

it

would

J

Can

be

difficult

to

trace

which

method

is

being

called

tools

help

K

Sometimes

Having

to

hunt

through

all

the

source

code

for

implementation

is

problematic

L

Depth

of

inheritance

an

issue

easy

to

understand

if

designed

well

M

related

to

depth

e.g.

if

you

have

to

trace

back

through

a

great

number

of

objects

to

see

what

method

is

implemented

then

yes

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

If

using

abstraction

properly

then

a

natural

way

of

writing

and

understanding

code

B

If

designed

properly

then

understanding

ok

C

If

designed

and

written

well

then

ok

it

's

likely

to

aid

understanding

D

No

great

impact

on

understanding

E

No

more

understanding

difficulties

than

with

structured

programs

F

If

the

abstractions

are

clear

then

understanding

should

be

ok

G

If

done

well

then

understanding

should

be

ok

H

Inheritance

simplifies

things

hence

better

understanding

it

simplifies

your

design

I

No

impact

on

understanding

it

causes

no

difficulty

J

No

problem

you

do

n't

have

to

deal

with

it

at

that

level

K

No

real

problem

L

The

hierarchy

should

be

defined

well

so

no

understanding

problem

M

I

do

n't

really

know

it

goes

back

to

the

design

the

functionality

spread

should

not

affect

me

that

much

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

If

abstraction

is

enforced

then

it

should

be

ok

if

it

is

n't

then

there

could

be

trouble

tracing

of

dependencies

can

be

difficult

but

tools

help

B

Can

be

difficult

if

inheritance

is

deep

difficult

to

trace

dependencies

C

If

well

written

then

ok

life

is

easier

D

Good

because

fix

it

for

one

fix

it

for

all

subclasses

E

Not

qualified

to

answer

F

No

experience

of

maintenance

G

Tracing

up

the

hierarchy

can

be

a

problem

H

No

more

difficult

than

tracing

C

function

calls

in

fact

its

more

structured

so

no

specific

problems

fix

it

for

one

fix

it

for

all

I

No

impact

programmers

do

n't

think

like

that

J

Depth

of

inheritance

is

an

issue

the

deeper

the

hierarchy

the

more

tracing

required

therefore

tools

are

important

K

Can

cause

problems

because

it

may

break

subclasses

who

use

the

method

that

's

been

changed

L

No

experience

of

maintenance

M

Inherent

object-orientation

has

made

it

easy

to

the

find

way

round

a

system

to

find

which

bit

was

requiring

maintenance

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

Able

to

design

at

highest

level

of

abstraction

B

Provides

modularity

and

prevents

code

redundancy

C

Aid

to

understanding

and

avoids

code

duplication

D

Simplifies

control

structure

of

methods

E

Provides

focus

for

powerful

abstraction

F

Reduces

redundancy

allows

abstraction

G

Helps

produce

nice

designs

at

the

conceptual

level

and

aids

understanding

H

No

duplication

of

functionality

simplifies

design

I

Reuse

of

specification

J

Information

hiding

and

encapsulation

K

Better

encapsulation

quick

prototyping

high

levels

of

abstraction

aid

to

understanding

simulates

the

real

world

L

Quick

prototyping

single

inheritance

good

for

design

M

inheritance

is

a

kind

of

implementation

thing

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

If

the

design

is

not

good

then

understanding

inheritance

is

a

problem

B

Speed

the

deeper

hierarchy

then

the

more

complexity

C

If

over

used

then

it

can

result

in

code

that

's

harder

to

follow

D

Tracing

the

flow

of

control

E

Misrepresenting

abstractions

is

a

problem

F

G

New

concept

to

learn

H

experienced

I

Multiple

inheritance

and

inappropriate

use

of

inheritance

J

Tracing

dependencies

what

method

is

this

attached

to

can

be

hard

to

answer

K

If

not

designed

properly

then

BIG

problems

L

Multiple

inheritance

M

Losing

your

way

in

the

hierarchy

-LRB-

related

to

depth

-RRB-

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

Single

inheritance

far

more

useful

B

Multiple

inheritance

complicates

things

and

software

reuse

is

harder

C

Use

multiple

inheritance

for

complex

applications

reuse

and

maintenance

is

easier

with

MI

D

Multiple

inheritance

useful

at

the

coding

level

E

Multiple

inheritance

maps

the

reality

of

the

system

F

Try

to

avoid

multiple

inheritance

G

Multiple

inheritance

a

big

problem

it

's

harder

SI

is

the

way

to

do

it

H

Multiple

inheritance

a

trojan

horse

it

makes

the

design

more

complex

I

Multiple

inheritance

is

n't

worth

the

extra

effort

it

's

more

complex

J

Multiple

inheritance

comes

very

naturally

K

Multiple

inheritance

can

be

messy

it

's

an

advantage

but

you

must

have

a

solid

case

for

using

it

L

Multiple

inheritance

allows

for

sloppy

approach

you

do

n't

really

need

it

more

tightly

coupled

and

reuse

is

harder

M

Multiple

inheritance

helped

to

underline

the

different

functionality

the

object

was

inheriting

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

Yes

it

can

but

it

's

related

to

the

learning

curve

these

do

disappear

B

No

more

problems

than

structured

code

difficult

for

those

who

do

n't

know

the

code

splitting

each

class

into

a

single

file

does

n't

help

C

Problems

if

people

doing

maintenance

do

n't

have

good

object-oriented

skills

but

if

these

skills

are

possessed

then

it

's

easier

D

No

problems

need

knowledge

of

basic

architecture

but

that

's

all

use

of

contractors

easier

for

OO

systems

they

can

get

up

to

speed

quicker

E

If

only

partial

knowledge

of

the

system

then

maintenance

difficulties

F

No

it

's

the

same

as

any

other

paradigm

abstraction

aids

maintenance

G

If

personnel

trained

properly

then

they

should

n't

have

problems

H

Less

problems

that

straight

C

OO

has

more

structure

I

If

designed

properly

then

objects

should

n't

need

maintenance

just

specialization

of

existing

classes

J

If

poorly

documented

K

One

file

per

class

idea

can

make

it

harder

but

tools

help

L

Few

systems

mature

enough

for

this

to

be

decided

M

Ca

n't

envisage

any

great

problems

from

it

my

experience

is

than

it

is

easier

to

maintain

object-oriented

code

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

Getting

into

OO

way

of

thinking

takes

time

learning

by

osmosis

I

Learning

curve

is

really

fierce

J

You

really

have

to

think

differently

I

'm

still

thinking

in

structured

C

in

some

ways

L

Almost

years

to

become

a

fully

conversant

object-oriented

programmer

Table

Remarks

made

about

the

learning

curve

Subject

Remark

A

Without

a

doubt

The

rate

of

entropy

leads

to

disorder

and

abstraction

will

eventually

be

lost

B

Quick

fixes

lead

to

unmaintainability

C

Yes

but

process

is

slower

than

with

structured

programs

D

Rate

of

entropy

reduced

it

's

slower

for

object-oriented

systems

E

There

is

a

lesser

tendency

but

must

keep

object-oriented

mindset

F

Yes

but

depends

on

the

design

of

the

changes

must

keep

abstractions

G

Slower

for

object-oriented

programs

H

If

quick

fixes

unmaintainability

ensues

corruption

of

the

design

I

Much

less

tendency

for

object-oriented

programs

J

Not

as

easily

for

object-oriented

programs

changes

made

are

object-oriented

then

the

systems

should

n't

become

a

mess

K

Less

likely

than

with

structured

programs

L

Less

so

with

object-oriented

programs

M

Yes

I

could

envisage

that

situation

occurring

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

A

lot

all

the

time

B

Very

limited

use

C++

C

for

C-flavours

RogueWave

for

C++

D

Extensive

in

past

limited

at

present

E

to

date

F

Pretty

limited

G

RogueWave

H

A

lot

for

Objective-C

limited

for

C++

easier

to

write

general

purpose

classes

in

Objective-C

I

A

lot

J

Use

bought

libraries

all

the

time

K

All

the

time

we

build

our

own

libraries

L

Extensive

use

of

own

libraries

M

Depends

on

what

's

available

beginning

to

in

C++

all

the

time

in

Objective-C

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

Yes

take

code

from

another

programmer

and

modify

it

for

new

requirements

no

for

commercial

libraries

B

No

for

commercial

libraries

very

limited

maintenance

and

limited

reuse

otherwise

C

No

for

bought

libraries

code

is

robust

D

Avoid

it

perhaps

specialization

but

not

modifying

the

original

code

E

No

experience

of

maintaining

class

libraries

F

Definitely

change

someone

else

's

code

to

meet

your

requirements

H

A

little

maintenance

but

nothing

major

I

No

class

libraries

tend

to

change

very

little

J

No

K

Yes

all

the

time

through

a

revision

control

procedure

L

More

so

than

a

single

programmer

might

do

trying

to

make

code

generic

as

possible

in

order

to

allow

reuse

M

No

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

No

there

is

no

distinction

between

libraries

and

application

B

Possible

but

if

well

written

then

libraries

do

n't

need

much

maintenance

C

Less

maintenance

likely

to

be

more

robust

than

new

code

if

used

before

but

need

good

version

and

configuration

control

D

No

being

tested

by

a

large

user

group

and

this

irons

out

the

bugs

quickly

stability

E

Depends

on

scaleability

of

class

libraries

need

version

and

configuration

control

F

Class

libraries

are

static

and

hence

reliable

so

no

G

Class

libraries

are

stable

once

they

've

been

debugged

so

no

H

In

my

experience

class

libraries

once

stable

are

changed

very

little

I

No

little

maintenance

of

class

libraries

once

stable

J

It

's

a

possible

scenario

but

it

's

not

happening

at

the

moment

K

Problems

get

ironed

out

as

you

use

it

so

no

L

Should

n't

have

to

maintain

libraries

-LRB-

Cox

's

maturity

index

a

good

idea

-RRB-

well

used

then

well

stressed

and

exercised

M

Depth

of

library

an

issue

incremental

development

with

maturity

index

should

prevent

maintenance

being

required

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

Code

must

be

put

through

code

review

guidelines

are

subjective

e.g.

do

n't

use

gotos

global

variables

but

bad

design

produces

bad

code

B

One

file

for

one

class

is

not

good

style

inconsistency

C

Long

methods

are

a

sign

that

something

wants

thinking

about

excessive

inheritance

depth

it

's

almost

less

the

coding

style

than

the

design

style

that

's

important

D

Short

methods

protected

instead

of

public

inheritance

where

possible

not

too

deep

an

inheritance

tree

E

I

've

not

enough

programming

experience

it

's

vital

that

common

programming

guidelines

are

accepted

though

F

Good

design

usually

means

good

code

we

have

code

reviews

earlier

now

G

I

do

n't

like

overloading

it

complicates

things

too

much

H

Should

have

code

reviews

to

sort

things

out

seems

to

be

few

points

of

reference

for

OO

code

quality

I

Identification

of

correct

objects

inappropriate

use

of

inheritance

all

at

the

design

level

J

Small

methods

mixing

object-oriented

code

with

procedural

code

is

sloppy

K

Mechanism

not

policy

-LRB-

based

on

good

design

-RRB-

L

Question

not

asked

M

Good

design

then

good

code

bad

design

then

bad

code

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

Difficult

to

say

changes

should

be

localized

only

when

encapsulation

is

broken

is

there

a

worry

code

reviews

help

B

Difficult

to

know

code

reviews

help

C

Its

no

more

impossible

than

under

the

procedural

type

of

method

breaking

encapsulation

is

a

bad

idea

code

reviews

help

D

No

but

this

is

true

of

any

system

E

It

depends

on

the

utility

of

the

method

changed

F

Use

metrics

and

code

reviews

to

check

so

yes

it

is

possible

G

No

but

a

code

review

should

spot

it

H

It

's

subjective

but

code

reviews

spot

these

things

I

Question

not

asked

J

Yes

the

changes

should

be

tested

adequately

and

encapsulated

K

No

difficult

to

tell

code

reviews

help

L

Encapsulation

so

it

should

not

have

degraded

M

Very

difficult

to

tell

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

Trouble

with

availability

and

quality

of

design

documentation

Subjects

B

C

D

F

G

H

J

K

M

made

similar

statements

E

Documentation

is

usually

available

G

Design

documentation

is

important

otherwise

you

are

back

to

where

you

were

before

L

Documentation

for

OO

programs

more

important

aid

to

understanding

than

documentation

for

non

OO

systems

M

The

documentation

is

essential

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

No

without

dynamic

binding

no

object-oriented

programming

B

No

really

useful

Objective-C

far

better

than

C++

for

it

C

No

it

allows

very

elegant

code

but

there

can

be

problems

of

finding

methods

bound

at

run-time

D

No

it

's

a

big

help

simplifies

the

code

it

's

more

intuitive

E

No

if

managed

well

it

maps

reality

F

No

good/clear

abstractions

are

aided

by

it

G

If

you

understand

it

then

it

causes

few

problems

H

No

it

makes

your

design

simpler

I

Question

not

asked

J

No

it

allows

generic

code

no

switches

etc

K

No

it

provides

lots

of

advantages

L

No

only

problem

is

calling

a

non

existent

method

M

Yes

if

you

are

careless

no

if

you

are

not

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

No

using

a

message

should

have

the

same

effect

on

any

object

that

responds

to

it

abstraction

B

Yes

it

's

a

great

benefit

but

it

can

make

things

difficult

to

understand

If

used

properly

and

sparingly

it

's

advantageous

C

Yes

it

produces

generic

code

but

easy

to

lose

track

of

what

's

going

on

D

No

it

simplifies

things

rather

than

making

them

more

difficult

you

are

looking

at

the

behaviour

of

each

object

but

not

the

details

E

Maintain

semantic

consistency

and

no

problem

otherwise

problems

F

No

methods

with

same

name

should

achieve

the

same

aim

G

Yes

but

related

to

learning

the

concept

H

It

simplifies

things

I

think

it

's

wonderful

I

It

's

the

most

important

property

in

OO

systems

but

must

maintain

high

level

semantics

J

It

can

cause

confusion

you

just

have

to

be

careful

K

No

problem

it

improves

understanding

L

It

's

an

aid

to

human

understanding

it

's

more

intuitive

M

No

problem

with

the

size

of

systems

I

've

looked

at

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

No

problems

perhaps

with

operator

overloading

but

tools

help

this

B

No

problems

but

I

avoid

operator

overloading

as

it

is

not

predictable

C

No

problems

no

operator

overloading

experience

D

Yes

naming

is

big

issue

in

object-oriented

programming

no

great

problems

with

operator

overloading

but

no

great

experience

either

E

No

real

experience

of

any

such

problems

F

Not

with

polymorphism

but

experience

of

operator

overloading

not

pleasant

G

No

but

little

use

operator

overloading

used

sensibly

then

useful

H

Yes

it

's

hard

to

know

the

best

time

to

use

the

same

names

I

This

is

one

of

the

major

hidden

problems

in

object-oriented

systems

programmers

must

understand

about

consistent

naming

Operator

overloading

for

thoroughly

defined

operators

only

J

experienced

no

use

of

operator

overloading

K

Yes

easily

make

a

mistake

renaming

a

member

function

and

this

can

lead

to

subtle

errors

that

are

hard

to

find

because

everything

looks

ok

L

Not

personally

M

No

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

It

's

been

hacked

together

without

much

thought

B

Syntax

of

it

can

be

very

obscure

C

Same

pitfalls

as

C

easy

to

write

C

in

C++

Regress

back

into

doing

something

in

a

C

fashion

when

they

should

be

doing

it

in

OO

fashion

D

Complicated

tries

to

do

everything

inconsistent

E

Unit

of

modularity

the

class

has

not

been

scaled

up

F

Same

problems

as

C

strong

typing

write

C

instead

of

C++

G

All

of

the

C

problems

H

Huge

monster

of

a

language

strongly

typed

obscure

I

Time

bomb

on

wheels

allows

bad

programmers

to

write

bad

object-oriented

code

J

Almost

programming

in

C

mixing

and

matching

paradigms

is

sloppy

K

Undefined

areas

-LRB-

e.g.

protected

inheritance

-RRB-

does

n't

look

object-oriented

does

n't

encourage

object-oriented

way

of

thinking

L

Does

n't

encourage

object-oriented

programming

you

may

write

C

instead

of

C++

it

's

strongly

typed

M

Strong

typing

sold

as

a

better

C

allows

you

to

feel

as

if

you

are

an

object-oriented

programmer

but

you

are

not

allows

you

to

write

C

not

forced

to

write

object-oriented

code

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

Its

efficiency

and

popularity

B

Its

fast

C

Its

performance

D

Familiarity

with

C

and

speed

E

Difficult

to

say

if

it

has

any

F

Control

over

everything

G

Its

performance

H

Its

performance

I

Allows

use

existing

C

libraries

and

OO

is

taking

off

because

of

C++

J

Its

efficiency

existing

C

libraries

K

More

efficient

L

Efficiency

and

it

's

street

credibility

M

Efficient

backed

by

AT&T

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

Yes

without

a

doubt

It

's

common

practice

Time

pressure

does

exist

B

It

depends

on

the

maintainer

It

's

easier

in

C++

C

Entirely

possible

Only

thing

you

can

do

in

the

time

D

Absolutely

someone

pushed

in

a

hurry

will

do

it

the

easiest

way

E

It

's

too

easy

in

C++

F

Yes

because

of

time

pressures

G

Yes

but

that

's

bad

maintenance

rather

than

design

H

There

's

a

good

chance

it

might

happen

I

've

only

done

it

once

I

Yes

particularly

in

C++

J

In

C++

a

lot

easier

to

do

quick

fix

depends

on

nature

of

the

project

as

well

as

individual

K

Yes

absolutely

L

One

of

the

dangers

in

these

hybrid

languages

M

It

's

all

too

easy

it

's

really

easy

and

the

temptation

is

always

there

Table

Answers

and

remarks

to

Q.

Subject

Remark

A

time

constraints

have

caused

quick

fixes

to

OO

code

in

the

past

Subjects

C

D

F

and

K

made

similar

statements

D

Must

try

to

remain

competitive

and

that

can

cause

quick

fixes

K

Documentation

is

the

first

thing

that

suffers

because

of

time

constraints

Table

Remarks

about

time

constraints

when

performing

quick

fixes