Managing Complexity and Change with Scalable Software Design


Published on

This is a presentation I gave to a group of IT managers. It explains what 'scalable design' is about, discusses its motivations by a number of facts and figures about software development, and illustrates the approach through a real-world case.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • (c) 2010 steX bv –
  • IS = Information Systems MIS = Management Information Systems (c) 2010 steX bv –
  • (c) 2010 steX bv –
  • BTW: this is very closely related to software architecture design, but then applied recursively until the remaining components are rather small individual building blocks. (c) 2010 steX bv –
  • focus here on the design part of technology.. SoC == divide and conquer (c) 2010 steX bv –
  • beloningssysteem aanpassen (c) 2010 steX bv –
  • 06/25/10
  • RoI factors: 400-4000% 70-1000% 150-700% -500% (c) 2010 steX bv –
  • 06/25/10
  • Managing Complexity and Change with Scalable Software Design

    2. 2. Software engineering: a 3D balancing act
    3. 3. Plan of this talk <ul><li>discuss impact of complexity and change on software project succes </li></ul><ul><li>present an approach to tackle this: ‘scalable design’ </li></ul><ul><ul><li>some of its ingredients </li></ul></ul><ul><ul><li>illustrated by a case (ASML) </li></ul></ul>
    4. 4. Challenges in software development <ul><li>managing complexity </li></ul><ul><ul><li>we build increasingly (inherently) complex systems </li></ul></ul><ul><ul><li>which carry more and more accidental complexity </li></ul></ul><ul><li>continuous change </li></ul><ul><ul><li>change starts on day one.. </li></ul></ul><ul><ul><li>causes large maintenance costs </li></ul></ul><ul><li>these are strongly related: </li></ul><ul><ul><li>Study by Banker (1993) : </li></ul></ul><ul><ul><li>25% of the maintenance costs are due to high complexity </li></ul></ul>
    5. 5. experience: complexity vs project risk source: Wallace, Keil & Rai, “Understanding software project risk: a cluster analysis”, Information & Management 42 (2004)
    6. 6. 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)
    7. 7. proportional maintenance costs source: Banker, “Software Complexity and Maintenance Costs”, CACM, Nov. 1993
    8. 8. Solution approach: scalable design <ul><li>A scalable design is a software design that can scale up with growing requirements and change requests . </li></ul><ul><li>goal: reduce costs of changes and extensions </li></ul><ul><ul><li>avoid “architectural detoriation” </li></ul></ul><ul><li>a new paradigm? </li></ul><ul><ul><li>no: just a coherent set of best practices </li></ul></ul><ul><ul><li>must be tailored to specific project & organization </li></ul></ul>
    9. 9. Scalable design approach - technology <ul><li>model-oriented (domain models) </li></ul><ul><ul><li>understand the core/essence </li></ul></ul><ul><ul><li>identify and focus on stable parts </li></ul></ul><ul><li>composition-oriented! </li></ul><ul><ul><li>separation of concerns </li></ul></ul><ul><ul><li>create variability by composing & configuring components </li></ul></ul><ul><ul><ul><li>not by source code & compiler directives & build files & XML files & configuration files & parameters & .. </li></ul></ul></ul><ul><ul><li>goal: conceptual integrity of the design </li></ul></ul>
    10. 10. Scalable design approach - people <ul><li>incremental growth & design iteration* </li></ul><ul><li>good separation of concerns: </li></ul><ul><ul><li> assigning jobs to right people (and lets them focus) </li></ul></ul><ul><li>the mindset of people must be adapted </li></ul><ul><ul><li>focus on long-term & variability </li></ul></ul><ul><ul><li>requires different evaluation/reward system. </li></ul></ul>source: fact 28 in R. Glass., “Facts and Fallacies of Software Engineering”, Addison-Wesley 2003
    11. 11. Scalable design approach - value <ul><li>work incremental: </li></ul><ul><ul><li>prioritize </li></ul></ul><ul><ul><li>build only what is needed </li></ul></ul><ul><ul><ul><li>but be prepared for the future! </li></ul></ul></ul><ul><li>scalable design yields systems that are much more flexible </li></ul><ul><ul><ul><li> this will make your business more flexible and agile </li></ul></ul></ul><ul><li>requirements will change during project </li></ul><ul><ul><li>a scalable design can better handle that </li></ul></ul>
    12. 12. Software Complexity in an Industrial Case: <ul><li>large embedded system in the lithography domain </li></ul><ul><ul><li>400 sensors, 300 actuators, 50 processors </li></ul></ul><ul><li>Software: 15-20 MLoC (mostly C) </li></ul>
    13. 13. Industrial case <ul><ul><li>4 concepts ‘crosscut’ the system (-30% of code) </li></ul></ul><ul><ul><li>error-prone, hard to maintain, ... </li></ul></ul>int get_kng(KNG_struct* KNG_ptr) { const char* func_name = &quot;get_kng&quot;; int result = OK; timing_handle timing_hdl = NULL; TIMING_IN; trace_in(mod_data.tr_handle, func_name); if (result == OK) { /* Retrieve current KNG */ *KNG_ptr = mod_data.KNG; } HE(result, &quot;GET_KNG FAILED&quot;); trace_out(mod_data.tr_handle, func_name, result); TIMING_OUT; return result; } primary functionality error handling
    14. 14. Industrial case: approach <ul><li>capture the essence of the 4 concepts </li></ul><ul><ul><li>separate these into independent abstractions </li></ul></ul>KNG_struct get_kng() { return ( mod_data.KNG); } note: ASML focused first on only one aspect
    15. 15. Industrial case: how to achieve this <ul><li>Technology: </li></ul><ul><ul><li>identify & implement core (crosscutting) concepts </li></ul></ul><ul><ul><ul><li>as general as possible but no more </li></ul></ul></ul><ul><ul><li>+ used special composition tooling (‘aspect weaver’) </li></ul></ul><ul><li>People: </li></ul><ul><ul><li>a few developers focus on crosscutting concerns </li></ul></ul><ul><ul><li>key benefit: developers make less mistakes! </li></ul></ul><ul><li>Value: </li></ul><ul><ul><li>business case focused on bug reduction </li></ul></ul><ul><ul><ul><li>+ consistency + simplicity + maintainability </li></ul></ul></ul>
    16. 16. Improvement potential source: Walker Royce, “Improving Software Economics”: IBM white paper (2009) costs (per person year) 10-35% 5-10% <5% 200-1000% 25-100% 15-35% 5-25% impact (productivity) 25-50%
    17. 17. Conclusion <ul><li>One empirical study* has shown that well-structured code is: </li></ul><ul><ul><li>2x easier to change </li></ul></ul><ul><ul><li>8x less prone to defects </li></ul></ul><ul><li>In addition: </li></ul><ul><ul><li>better project predictability </li></ul></ul><ul><ul><li>flexible products (=flexible business) </li></ul></ul><ul><li>By consistently applying existing techniques: </li></ul><ul><ul><li>scalable designs are feasible & worthwhile </li></ul></ul>* source:a study by The Software Technology Support Center and The Mitre Corporation
    18. 18. Questions?
    19. 19. questions/discussion items <ul><li>in your practice, do you think complexity of software is a key factor in project success? </li></ul><ul><li>how important is maintainability of software for you? </li></ul><ul><ul><li>how big are maintenance costs (relative to overall costs)? </li></ul></ul><ul><li>how do you try to achieve/receive maintainable software? </li></ul><ul><ul><li>and how do you assess this? </li></ul></ul>
    20. 20.
    21. 21. Applicability of scalable design <ul><li>NO if: </li></ul><ul><ul><li>the requirements are completely fixed (..) </li></ul></ul><ul><ul><li>the size of the software is so small one person can keep it in his/her head </li></ul></ul><ul><ul><li>you do not care about costs after first release </li></ul></ul><ul><li>YES if: </li></ul><ul><ul><li>requirements may change/improve/become more detailed </li></ul></ul><ul><ul><li>there is even a modest size or complexity </li></ul></ul>
    22. 22. Wat can you do? <ul><li>as a customer : evaluate projects differently: </li></ul><ul><ul><li>e.g. include life-cycle costs </li></ul></ul><ul><ul><ul><li>what are costs of realizing new/changing requirements? </li></ul></ul></ul><ul><ul><ul><li>measure economical lifespan of products? </li></ul></ul></ul><ul><ul><li>acceptance test could include change scenarios </li></ul></ul><ul><ul><ul><li>see: architectural assessment (e.g. SAAM) </li></ul></ul></ul><ul><li>as project management : </li></ul><ul><ul><li>create a culture that supports scalable design </li></ul></ul><ul><ul><ul><li>but avoid big, isolated, efforts! </li></ul></ul></ul><ul><ul><ul><ul><li>e.g. large framework investments decoupled from projects </li></ul></ul></ul></ul>
    23. 23. Scalable Design Paradox <ul><li>design is an iterative process... * </li></ul><ul><ul><li>this means that the first design is never the right & final one. </li></ul></ul><ul><ul><li>it implies that getting the ‘right’ scalable design the first time is impossible </li></ul></ul><ul><ul><li>and that any design will repeatedly change </li></ul></ul><ul><li>when you start with a scalable design: </li></ul><ul><ul><li>you will be able to handle the changes much easier </li></ul></ul><ul><ul><li>iterations have less impact on the overall system! </li></ul></ul><ul><li>this implies that a scalable design pays back early!!   </li></ul>source: fact 28 in R. Glass., “Facts and Fallacies of Software Engineering”, Addison-Wesley 2003
    24. 24. <ul><ul><ul><ul><li>Slide </li></ul></ul></ul></ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.