MANAGING COMPLEXITY & CHANGEWITH SCALABLE SOFTWARE DESIGN

Lodewijk Bergmans

Software engineering: a 3D balancing act

2

Plan of this talk

discuss impact of complexity and change on software project succes

present an approach to tackle this: ‘scalable design’ some of its ingredients illustrated by a case (ASML)

3

Challenges in software development

1. managing complexity we build increasingly (inherently) complex systems which carry more and more accidental complexity

2. continuous change change starts on day one.. causes large maintenance costs

these are strongly related: Study by Banker et.al. (1993) : 25% of the maintenance costs are due to high

complexity

4

experience: complexity vs project risk

source: Wallace, Keil & Rai, “Understanding software project risk: a cluster analysis”, Information & Management 42 (2004)

5

The only constant: Change

Year maintenance costs (%)

Definition Reference

2000 >90% sw.cost devoted to system maintenance & evolution / total sw. costs

Erlikh (2000)

1993 75% sw. maintenance / IS budget (in Fortune 1000 companies)

Eastwood (1993)

1990 >90% sw. cost devoted to system maintenance & evolution / total sw. costs

Moad (1990)

1990 60-70% sw. maintenance / total MIS operating budgets

Huff (1990)

1988 60-70% sw. maintenance / total MIS operating budgets

Port (1988)

1984 65-75% Effort spent on sw. maintenance / total available SE effort.

McKee (1984)

1981 >50% Staff time spent on maintenance / total time (in 487 organizations)

Lientz & Swanson (1981)

1979 67% Maintenance costs / total sw. costs Zelkowitz et al.(1979)

6

proportional maintenance costs

source: Banker et.al., “Software Complexity and Maintenance Costs”, CACM, Nov. 1993

7

Solution approach: scalable design

A scalable design is a software design that can scale up with growing requirements and change requests.

goal: reduce costs of changes and extensions avoid “architectural detoriation”

a new paradigm? no: just a coherent set of best practices must be tailored to specific project & organization

8

Scalable design approach - technology

model-oriented (domain models) understand the core/essence identify and focus on stable parts

composition-oriented! separation of concerns create variability by composing & configuring

components not by source code & compiler directives & build files &

XML files & configuration files & parameters & .. goal: conceptual integrity of the design

9

Scalable design approach - people

incremental growth & design iteration* good separation of concerns:

assigning jobs to right people (and lets them focus) the mindset of people must be adapted

focus on long-term & variability requires different evaluation/reward system.

source: fact 28 in R. Glass., “Facts and Fallacies of Software Engineering”, Addison-Wesley 2003

10

Scalable design approach - value

work incremental: prioritize build only what is needed

but be prepared for the future! scalable design yields systems that are much more

flexible this will make your business more flexible and agile

requirements will change during project a scalable design can better handle that

11

Software Complexityin an Industrial Case:

large embedded system in the lithography domain 400 sensors, 300 actuators, 50 processors

Software: 15-20 MLoC (mostly C)

12

Industrial case

4 concepts ‘crosscut’ the system (-30% of code) error-prone, hard to maintain, ...

intint get_kng(KNG_struct* KNG_ptr) get_kng(KNG_struct* KNG_ptr){{ const char* func_name = "get_kng";const char* func_name = "get_kng"; int result = OK;int result = OK;

timing_handle timing_hdl = NULL;timing_handle timing_hdl = NULL; TIMING_IN;TIMING_IN;

trace_in(mod_data.tr_handle, func_name);trace_in(mod_data.tr_handle, func_name);

if (result == OK)if (result == OK) {{ /* Retrieve current KNG *//* Retrieve current KNG */ *KNG_ptr = mod_data.KNG;*KNG_ptr = mod_data.KNG; }} HE(result, "GET_KNG FAILED");HE(result, "GET_KNG FAILED");

trace_out(mod_data.tr_handle, func_name, result);trace_out(mod_data.tr_handle, func_name, result); TIMING_OUT;TIMING_OUT; return result;return result;}}

primary functionality

error handling

13

Industrial case: approach

capture the essence of the 4 concepts separate these into independent abstractions

KNG_struct KNG_struct get_kng()get_kng(){{

return ( mod_data.KNG);return ( mod_data.KNG);}}

note: ASML focused first on only one aspect

14

Industrial case: how to achieve this

Technology: identify & implement core (crosscutting) concepts

as general as possible but no more + used special composition tooling (‘aspect weaver’)

People: a few developers focus on crosscutting concerns key benefit: developers make less mistakes!

Value: business case focused on bug reduction

+ consistency + simplicity + maintainability

15

Improvement potential

source: Walker Royce, “Improving Software Economics”: IBM white paper (2009)

cost

s (p

er

pers

on

year)

cost

s (p

er

pers

on

year)

10-35%10-35%

5-10%5-10% <5%<5%

200-1000%200-

1000%

25-100%25-

100% 15-35%15-35% 5-25%5-25%

imp

act

(p

rodu

ctiv

ity)

imp

act

(p

rodu

ctiv

ity)

25-50%25-50%

16

Conclusion

One empirical study* has shown that well-structured code is: 2x easier to change 8x less prone to defects

In addition: better project predictability flexible products (=flexible business)

By consistently applying existing techniques: scalable designs are feasible & worthwhile

* source:a study by The Software Technology Support Center and The Mitre Corporation

17

Questions?18

questions/discussion items

in your practice, do you think complexity of software is a key factor in project success?

how important is maintainability of software for you? how big are maintenance costs (relative to overall

costs)? how do you try to achieve/receive maintainable

software? and how do you assess this?

19

20

Applicability of scalable design

NO if: the requirements are

completely fixed (..) the size of the

software is so small one person can keep it in his/her head

you do not care about costs after first release

YES if: requirements may

change/improve/become more detailed

there is even a modest size or complexity

21

Wat can you do?

as a customer: evaluate projects differently: e.g. include life-cycle costs

what are costs of realizing new/changing requirements? measure economical lifespan of products?

acceptance test could include change scenarios see: architectural assessment (e.g. SAAM)

as project management: create a culture that supports scalable design

but avoid big, isolated, efforts! e.g. large framework investments decoupled from projects

22