E N A B L I N G E F F I C I E N T H E A L T H C A R E Mufrid Krilic Senior Software Developer/Coach DIPS AS, Norway @mufridk Building Quality In Legacy Systems – The Art of Asking Questions Her kan du legge inn bilde. Du finner figurer her: Link

Maslow’s Hierarchy of Needs

Gojko Adzic - Using Maslow as an Analogy for Defining Software Quality Blogpost: • «Redefining Software Quality» • https://gojko.net/2012/05/08/redefining-software-quality/

Maslow - Physiological Needs • Quality methods: • TDD • Correct metrics: • Bug count • Code Coverage Roles to focus on: • Beta-users • Operations

Maslow – Safety Needs • Quality methods: • Performance testing • Risk analysis • Architecture and design patterns Roles to focus on: • End-users • People working with information security

Maslow – Love/Belonging Needs • Quality methods: • Usability testing • Design thinking • UX design Roles to focus on: • End-users

Maslow – Esteem Needs • Quality methods: • Continuous delivery • DevOps • Correct metrics • Production environment measurements Roles to focus on: • End-users, Management

Maslow – Self-actualization Needs • Quality methods: • Impact Mapping • Correct metrics • What impact did the software product make? • Did we make or save money? Roles to focus on: • Decision makers • Broader user community • Public relations

Good enough – how to know where to invest? The more you invest in quality on this level the better Focus on good enough

How to apply this when working with legacy systems? The Art of Asking Questions

Different perspectives in the legacy system  Ask questions related to – Delivery process – Conditions of acceptance – Code and product maintainability – Security and performance – Domain-specific context in existing operational environments

Delivery process related questions  Documentation  Any manual steps in the delivery process?  Compatibility with previously installed versions in production – Can multiple versions of the product exist side by side? Deployable?

Conditions of Acceptance  Testing integration points with other parts of the system – What are my dependencies? – How to avoid introducing undesirable behavior? – Learn from experiences of the past – Talk to people in your organization   Invest in exploratory testing Functionally ok?

Code and product maintainability related questions  Diagrams and maps – How to document integrations with other parts of the application?  Versioning – Consider releasing only parts of the legacy system if possible  Logging/Profiling – Do we have enough logging to be able to monitor usage in production? Functionally ok?

Security and performance related questions  Performance testing  Memory leaks, memory footprint  Authentication, authorization, audit  Code analysis for discovering patterns that could lead to bugs in production – Asynchronous communication patterns – Multithreading issues Performant, secure?

Domain-specific context in existing operational environments  How is the legacy system used today? – To what extent will users’ behavior change with new functionality?  Compatibility with specific configurations customers may have applied on-site  Consider constraints that may be imposed by customers’ organizational structure – Operational environment decisions • E.g. moving to data centers Usable? Useful? The most challenging questions to address

What about “Successful” ? Product management approach Design approach

Summary: Mapping of different perspectives to the software quality pyramid Conditions of acceptance Delivery process Code and product maintainability Security and performance Domain-specific context in existing operational environments

The Consequence of Applying this Approach • Relentless learning • Strengthening the team’s ability in decision-making • Consequence is that every piece of work is bigger than initially assumed • Choose a set of questions that work for you at the time • Then gradually expand The Takeaway

Thank you!  Blog: www.medium.com/@mufridk  Twitter @mufridk