Guest Lecture at Melbourne Uni 23 May 2018

1. APROJECT
MANAGER’S
SURVIVAL GUIDE
Daniel Aragao
Theresa Neate
1
QUALITY IN
SOFTWARE
EDITION

2. DISCLAIMER
This lecture aims to give future Project Managers
an insight into relevant thoughts, tools, practices,
techniques and useful ideas on how produce good
quality bespoke software. This means that the
product you’re helping create is software.
So, picture yourself as a Project Manager working
for Target on their new iPhone app project or at
Netflix’s next generation website.
Let’s get started!
2

3. HERE’S WHAT WE’LL TRY TO COVER
•Intro
•Ways of working
•Vague definitions
•What to focus on
•Design quality
•Code quality
•Security quality
•So what do PMs do with respect to quality?
•Anti-patterns
3

4. ABOUT US
4
Dan Aragao
I’m an all rounder software guy, Agile project manager and
developer.
Currently the Lead Architect at Australia’s largest digital
business, REA Group - aka realestate.com.au
Theresa Neate
I love all things software quality, especially proactive QA.
Currently the Lead QA & Developer Advocate at Australia’s
largest digital business, REA Group - aka realestate.com.au

5. WAYS OF WORKING
or why Taylor and Fayol ruined it for us
5

6. WHAT ARE YOU BUILDING?
6

7. WHAT ARE YOU BUILDING?
7

8. MANAGEMENT STYLE MATTERS
8
VS

9. BUILDING BESPOKE SOFTWARE INCREMENTALLY
9

10. BUILDING BESPOKE SOFTWARE ITERATIVELY
10

11. SLICING THE WORK IN BETTER WAYS
•Deliver the bare minimum value
11

12. AGILE SOFTWARE DEVELOPMENT
12

13. WHAT'S THE ORG STRUCTURE?
13

14. WHAT'S THE COMMS STRUCTURE?
14

15. WHAT'S THE COMMS STRUCTURE?
15

16. WHAT GAME ARE YOU PLAYING?
16

17. VAGUE DEFINITIONS
or, an argument about why quality to me is different than quality to you
17

18. DO WE HAVE ANY DEFINITIONS?
•There is no catch-all definition
•It’s OK because we believe that there are no best practices
to follow; only good ideas to leverage
•Things vary by context
•(Tell us examples)
18

19. SOME VAGUE DEFINITIONS (TELL US EXAMPLES)
•Lack of defects ( bugs )… but wait, every piece of
software has bugs
•Available
•Responsive
•Maintainable
•Cost effective
•Functional
•Attractive and easy to use
•Beautiful, performant code
•Secure
19

20. QUALITYATTRIBUTES TAXONOMY
Still not clear… Consider a system failure due to a denial-of-
service attack. Is it an aspect of availability, performance,
security, or usability?
20

21. WHATTO FOCUS ON
because you cannot address all quality attributes
21

22. STRUCTURE YOUR OWN QUESTIONS ON QUALITY
22
cost
time quality

23. WHAT REALLY MATTERS
•Is there a standard to follow? (CMMI, ISO, PMBOK,
PRINCE, etc)
•Who builds quality?
•How measure and track quality?
•How much does quality cost and how much should be
invested?
•When to start focusing on quality?
•What details should be written down on a contract?
•How does quality differ from value?
•Do all software delivery approaches address quality?
23

24. WHAT REALLY MATTERS
•How does risk relate to quality?
•Do I need specialised people?
•Isn’t testing enough?
•How can I “detect” poor quality in software?
•How do I know I’ve done enough?
•Does our way of working hinder or foster quality?
24

25. DESIGN QUALITY
25

26. DEPRECIATION AND OBSOLESCENCE BY DESIGN
26

27. COST OF OWNERSHIP
27

28. UI IS IMPORTANT
28

29. EXPECTATION MANAGEMENT
•Change and objection management
•Transparency
•Conflict and compromise
•Influencing - creating desire and avoiding rejection
•Tools to do it
• Rapid prototyping
• Pairing and collaborative development
• User testing - Steve Krug’s style
29

30. EXPECTATION MANAGEMENT
•When in doubt talk to the team about the best
way to do it or ask for help
•Poka-yoke - safe designs
30

31. CODE QUALITY
all the stuff that’s hard to see
31

32. WHAT TO TEST?
32
•Usability - crazyegg, hotlog, eye tracking glasses
•Performance - pingdom
•Team happiness
•Unit, integration, functional tests
•Test Coverage

33. TESTING CODE - CUPCAKE STYLE
33

34. TESTING CODE - PYRAMID STYLE
34

35. WHICH INTERNAL QUALITY METRICS TO MEASURE?
35
•Cyclomatic Complexity
•Duplication
•Fan-in, fan-out
•Dependency hell
•Size

36. HOW TO SEE INTERNAL QUALITY?
36
Visualisation (TreeMap)

37. EASY TO COMPARE
37

38. 38

39. AUTOMATION INCREASES QUALITY
39

40. WHAT IS MORE IMPORTANT?
•Invest in a testing phase pre-launch to
ensure no bugs get out
or
•Invest in a release pipeline that allows
pushing code to production whenever
needed
40

41. SECURITY QUALITY
what if … kaboom!
41

42. THINGS TO THINK OF
•Why care? Think of what happened with Code Spaces
•or Knight Capital - $440m in 45 mins
•Penetration testing - don’t assume Developers know what
they are doing all the time
•Integrity, availability and confidentiality
•Disaster recovery and business continuity - now!
•Things fail, don’t be optimistic, build for failure
•OAIC NDB starts 22 Feb 2018
42

43. THINGS TO THINK OF
•Plan for incidents, know how to communicate
43

44. SOME INTERESTING TOOLS
44
Bees with Machine Guns

45. SO WHAT DO PM’S
DO WITH RESPECT
TO QUALITY
or should do
45

46. THINGS PROJECT MANAGERS DO
•Continuously plan a quality plan that matches the
purpose
• Have metrics and data
•Ensure fast feedback loops exist and invest to make
them faster
•Create teams around slices instead of silos -
Conway’s law
•Delegate quality to the team and make them
accountable
46

47. THINGS PROJECT MANAGERS DO
•Assess team’s ability drive the quality needed and
request help as needed
• Consultants
• Training
• Meetups
•Less is more, aim to do just enough and no more.
The only way to introduce bugs is by writing code
47

48. THINGS PROJECT MANAGERS DO
•Think past project delivery
•Encourage/prefer Devops, team managed
infrastructure and data
•Aim for no-handovers
•Think about security, plan for being attacked
•Have a disaster recovery plan and exercise it
•Understand your testing pyramid and make it look
the way it should
48

49. THINGS PROJECT MANAGERS DO
•Invest in knowledge sharing, because in software, negative
productivity is real
•Invest in tools that bring visibility and foster discussions on
the results. i.e. Structure 101
•Encourage the use of static code analysis tools. i.e. simian,
rubocop, checkstyle, lint
•Create a healthy balance between different quality
perspectives
•Invest in automation and Continuous Integration and
Delivery from day zero - Travis CI, BuildKite, Go CD, etc
49

50. EXERCISE
try it now
50

51. FOOD FOR THOUGHT
You’ve just started a new job as a PM you’ll
need to extend an existing legacy system.
What questions would you ask your team to
ensure you’ll build quality in?
51

52. ANTI-PATTERNS
or should NOT do
52

53. 53
TRY NOT TO DO THESE THINGS
53
• Tolerate no or long feedback cycles
• Delay integration
• Isolate team from end-users
• Hide internal quality, progress and problems
• Assess quality based exclusively on functionality
• Organise team and work around functional silos
or architecture pieces
• Code without source control

54. 54
TRY NOT TO DO THESE THINGS
54
•Little care about people’s happiness, aspirations
and ambitions
•Trying to produce by adding more people without
accounting for communication costs
•Allowing people to burn out

55. D a n i e l s a y s :
THANK YOU
&
QUESTIONS??
dan.aragao@rea-group.com
theresaneate.com
REA Graduate Programme
http://careers.realestate.com.au/graduate-programme