The goal of being able to build quality in software products from the get-go is something that many organizations are trying to achieve. However, the very definition of software quality is somewhat elusive which makes it difficult to agree upon the perceived level of quality in software products. Moreover, working with legacy systems poses its own set of challenges as uncertainty of preserving overall quality in the legacy product seems to be an everyday struggle for many teams. This talk builds on a multi-perspective definition suggested by Gojko Adzic in his blogpost “Redefining Software Quality” some years ago. For each perspective a series of well-defined questions will be presented that help teams challenge its own assumptions about quality in the end-product. The talk is based on practical applications of Gojko’s definition as embraced by the teams working on a legacy enterprise software in healthcare domain.

1. 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

2. Maslow’s Hierarchy of Needs

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

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

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

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

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

8. 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

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

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

11. 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

12. 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?

13. 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?

14. 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?

15. 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?

16. 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

17. What about “Successful” ?
Product management approach
Design approach

18. 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

19. 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

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