Software engineering practices have matured tremendously in recent years, but too often they are applied thoughtlessly and without a true understanding of why or when they might be applicable. Frequently, engineers will debate the "best" or "correct" way to do things without wider reference to the problem at hand. In this talk I will show how a pragmatic approach to quality is required if we are to truly make digital products that matter.

1. QUALITY IS A
VARIABLE
James Higgs
@higgis

2. “We launch valuable products,
services and companies that make a
measurable difference to the world.
4
Studios
200
People
22
Nationalities

3. Whether our iconic game Monument Valley or
innovative technical platform Wayfindr, for 10 years
we’ve create products with passion from conception
to launch and beyond.
AWARD-WINNING
OWN PRODUCTS
AND GAMES
APPLE
DESIGN AWARD
WINNER 2015
BAFTA
BEST BRITISH
WINNER 2015
APPLE GAME
OF THE YEAR
WINNER 2015

4. MONUMENT
VALLEY
10,000,000
DOWNLOADS
The ustwo games team conceived and built Monument
Valley in 10 months with continuous user testing with
gamers and non-gamers to achieve a magical and
intuitive puzzle game experience with mass appeal.
MULTI-AWARD
WINNING
2014
$8,000,000
REVENUE

5. INNOVATIVE
CLIENT WORK
We partner with smart clients to launch new
products, services and companies that are of
strategic importance and reliant on innovation.

6. WE ARE
PRODUCT
ENGINEERS

7. EVERYTHING I SAY TODAY
WILL BE ABOUT DELIVERING
END-USER SOFTWARE.

8. PRODUCT ENGINEERS SERVE
THE NEEDS OF USERS
THROUGH THE PRODUCT

9. YOU WILL NOTE THAT I DID
NOT MENTION CODE IN
THAT DEFINITION

10. WE DO THINGS TO MAKE THE
PRODUCT BETTER, NOT TO MAKE
OUR LIVES AS ENGINEERS EASIER

11. WE MAKE OUR ENGINEERING
LIVES EASIER ONLY IN SO FAR AS
THAT HELPS THE PRODUCT

12. ONE OF THE BIGGEST ISSUES I
SEE IN OUR INDUSTRY TODAY
IS OVER-ENGINEERING

13. OVER-ENGINEERING IS WHERE
YOU PRIVILEGE GUESSES ABOUT
THE FUTURE OVER FACTS ABOUT
THE PRESENT

14. OVER-ENGINEERING IS WHERE
YOU MAKE THINGS THAT ARE
SUFFICIENTLY EASY MORE
COMPLICATED

15. YOU WILL QUITE OFTEN HEAR
ENGINEERS REFER TO THEMSELVES
AS “CRAFTSMEN”

16. WHEN A POTTER MAKES A POT,
SHE TOUCHES IT WITH HER HANDS,
AND YOU TOUCH THE SAME
PHYSICAL THING THAT SHE DID

17. USERS DON’T CARE HOW
YOUR CODE IS STRUCTURED

18. IN FACT THEY NEVER SEE
OR TOUCH YOUR CODE

19. THAT’S BECAUSE CODE IS A
TRANSITIONAL ARTEFACT

21. MOZART, PERHAPS THE GREATEST
COMPOSER IN HISTORY, WAS
HIGHLY PRAGMATIC. HE WANTED
HIS MUSIC PLAYED.

22. OUR CODE IS TO OUR PRODUCTS
WHAT MOZART’S MANUSCRIPTS
ARE TO PERFORMANCES OF HIS
MUSIC

23. CARING ABOUT YOUR CODE AS AN
END IN ITSELF IS LIKE MOZART
WORRYING ABOUT HIS
HANDWRITING

24. I QUICKLY GOOGLED
“WHY DO REFACTORING”

25. DO IT “RIGHT”
I am a huge proponent of writing quality code, a view that is shared by many of my
colleagues. Unfortunately, I do encounter those who do not share my enthusiasm.
Their view is often one of “Get It Done,” whereas I take the position of “Get It Done
Right.” - Chris Eargle
5. Your Code Sucks
4. Debts Accrue Interest
3. Repetition Is Dangerous
2. Spaghetti Is Good to Eat, Bad to Read
1. Littering Is Rude
None of these issues
directly concern the
user of the software

26. IF YOU LEAVE HERE WITH
ONLY ONE MESSAGE, IT
SHOULD BE THIS...

27. THERE IS NO
“RIGHT WAY”

28. IN FACT, THERE ARE ONLY TWO
THINGS THAT SHOULD MATTER
TO A PRODUCT ENGINEER

29. CORRECTNESS
REASONABLE
MEDIUM TERM
PRODUCTIVITY
features, perf, security
shipping features that users want
and improving them thereafter

30. TEXTMATE

31. UNRELEASED CODE IS AN
INVESTMENT THAT CANNOT
PAY OFF

32. THIS IS WHAT LEAN ADVOCATES
CALL “INVENTORY”

33. YOU GOAL SHOULD BE TO
SHIP CODE AS SOON AS
YOU POSSIBLY CAN

34. AND THIS MEANS MAKING THE
SIMPLEST THING THAT COULD
POSSIBLY WORK

35. AND SO I COME BACK TO THE
PLAGUE OF OVER-ENGINEERING

36. SOFTWARE ENGINEERS’ OWN
ESTIMATION OF QUALITY IS
MEANINGLESS

37. THE QUALITY REQUIRED IS THAT
WHICH ALLOWS YOU TO SHIP
USEFUL FEATURES AT A CADENCE
THAT WORKS FOR THE USER

38. IF THE QUALITY IS TOO HIGH,
THE CADENCE WILL BE TOO SLOW

39. IF THE QUALITY IS TOO LOW,
EVENTUALLY IT WILL BE IMPOSSIBLE
TO ADD FEATURES AT ALL

40. REFACTORING IS WHAT WE DO
WHEN ADDING A FEATURE IS
HARDER THAN IT NEEDS TO BE

41. WE REFACTOR SOLELY BECAUSE
THERE IS VALUE TO THE USER IN
DOING SO

42. THE CODE WILL BE CLEANER!
NO
THE CODE WILL BE EASIER TO TEST!
NO
THERE WILLL BE LESS REPETITION!
NO

43. WE HAVE COME UP WITH VERY
ELABORATE SOLUTIONS TO THINGS
THAT ARE ALREADY SUFFICIENTLY
EASY (BUT REPETITIVE)

44. COPY AND PASTE IS OFTEN THE
BEST WAY TO REUSE CODE

45. ALL SOFTWARE ENGINEERING
TECHNIQUES ARE A MEANS TO AN
END, NOT A MORAL IMPERATIVE

46. SO, LET’S TALK ABOUT THE
OBVIOUS OBJECTION TO THIS
PHILOSOPHY

47. TECHNICAL
DEBT

48. TECHNICAL DEBT IS WHERE YOU
DO SOMETHING IN A WAY THAT
YOU THINK WILL NEED
IMPROVEMENT IN FUTURE, BUT
WHICH WORKS NOW

49. DEBT IS NOT BAD! IT’S A WAY OF
GETTING AHEAD OF THE GAME IF
USED RESPONSIBLY

50. CORE TO THE AGILE PHILOSOPHY
IS THE CONCEPT OF ITERATION.
ITERATE: TO DO AGAIN

51. TODAY’S ENGINEERS WILL GO TO
EXTRAORDINARY LENGTHS TO
AVOID DOING SOMETHING AGAIN

52. IT IS A FUNDAMENTAL ERROR TO
TRY TO SOLVE A PROBLEM
DEFINITIVELY ON THE FIRST TRY

53. BECAUSE WE DON’T EVEN KNOW
IF A FEATURE IS WORTH HAVING
UNTIL USERS HAVE USED IT

54. IT MAKES NO SENSE TO SPEND
A LOT OF MONEY GETTING
SOMETHING EXACTLY RIGHT
WITHOUT KNOWING IF IT’S
NEEDED

55. THIS IS WHY IN AGILE WE USE A
LIMITED TIME HORIZON; BEYOND
THAT WE ARE GUESSING

56. ENGINEERS HAVE SCARED
NON-ENGINEERS WITH
“TECHNICAL DEBT” FOR
TOO LONG

57. HERE’S MY CHALLENGE TO YOU:
QUANTIFY IT.

58. MANY ENGINEERS WILL ASSERT
THAT A GIVEN APPROACH IS
“BETTER” BUT FAIL TO EXPLAIN
HOW IN TERMS THAT MATTER
TO THE PRODUCT IN THE
FORESEEABLE FUTURE

59. MOST OF THE TIME WE’RE TOLD
IT’S GOING TO HAVE DIRE
CONSEQUENCES LATER IF WE
DON’T DO IT “THE RIGHT WAY”

60. ARE YOU CERTAIN THAT THE
FUTURE CHANGE WILL NEED TO BE
MADE?
ARE YOU CERTAIN THAT SLOWING
THINGS DOWN IS THE BEST
OPTION NOW?

61. BUT THIS PRESUPPOSES SOME
PRECISE KNOWLEDGE ABOUT THE
FUTURE THAT WE DON’T YET HAVE

62. SO, NEVER MIND TECHNICAL DEBT
LET’S TALK ABOUT TECHNICAL BETS

63. ENGINEERS WHO WANT TO INVEST
IN DOING THINGS THE “RIGHT
WAY” SHOULD SHOW WHERE THE
VALUE IS TO THE USER.

64. WHEN YOU CHOOSE TO MAKE A
TECHNICAL BET, GO BACK AND
MEASURE WHETHER IT WAS
WORTH IT

65. DO NOT FALL PREY TO
RETROSPECTIVE DETERMINISM

66. YOU MAY LOOK BACK AND THINK
YOU SHOULD HAVE MADE THE BET,
BUT BY THAT LOGIC YOU SHOULD
HAVE PLAYED LAST WEEK’S
LOTTERY

67. AND ALSO CONSIDER:
EVEN IF I WOULD HAVE WON THE
BET, WAS IT THE RIGHT TIME TO
MAKE IT?

68. TO BREAK EVEN ON A TECHNICAL
BET, YOU MUST LATER SAVE
DOUBLE THE TIME IT TAKES TO
MAKE IT

69. LEARN ABOUT OPPORTUNITY
COST
The loss of other alternatives when
one alternative is chosen“

70. OFTEN THIS MEANS CHOOSING
BETWEEN A USER FEATURE AND
A TECHNICAL BET

71. WE KNOW THE USERS WANT THIS
FEATURE NOW. IS YOUR BET
GOING TO PAY OFF BIG ENOUGH?

72. START BY NOT BETTING ON
MAKING SUFFICIENTLY EASY
THINGS EASIER

73. EVERYTHING EXTERNAL TO THE
PRODUCT - LIKE DOCUMENTATION-
SHOULD BE ELIMINATED UNTIL
THERE IS EVIDENCE IT'S NEEDED

74. “The critical question for any
practice is: does it help us
get better (or more, or
faster) feedback on whether
the software is useful?
- Sarah Mei

75. IT TAKES REAL DISCIPLINE AND
THOUGHT TO MAKE THE RIGHT
TRADEOFFS FOR A PRODUCT

76. A PRODUCT IS LIKE A GREAT CITY:
NEVER FINISHED, CONSTANTLY
CHANGING, ALWAYS ADAPTING
TO USE

77. ASK YOURSELF AND YOUR
TEAM: ARE WE OVER
PRIORITISING THE FUTURE?

78. KEEP THINGS SIMPLE, MOVE
AS QUICKLY AS YOU CAN,
DON’T BE AFRAID TO GO
OVER THINGS AGAIN

79. THANK YOU!