Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[Keynote] James Higgs - Quality is a variable

830 views

Published on

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.

Published in: Technology

[Keynote] James Higgs - Quality is a variable

  1. 1. QUALITY IS A VARIABLE James Higgs @higgis
  2. 2. “We launch valuable products, services and companies that make a measurable difference to the world. 4 Studios 200 People 22 Nationalities
  3. 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. 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. 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. 6. WE ARE PRODUCT ENGINEERS
  7. 7. EVERYTHING I SAY TODAY WILL BE ABOUT DELIVERING END-USER SOFTWARE.
  8. 8. PRODUCT ENGINEERS SERVE THE NEEDS OF USERS THROUGH THE PRODUCT
  9. 9. YOU WILL NOTE THAT I DID NOT MENTION CODE IN THAT DEFINITION
  10. 10. WE DO THINGS TO MAKE THE PRODUCT BETTER, NOT TO MAKE OUR LIVES AS ENGINEERS EASIER
  11. 11. WE MAKE OUR ENGINEERING LIVES EASIER ONLY IN SO FAR AS THAT HELPS THE PRODUCT
  12. 12. ONE OF THE BIGGEST ISSUES I SEE IN OUR INDUSTRY TODAY IS OVER-ENGINEERING
  13. 13. OVER-ENGINEERING IS WHERE YOU PRIVILEGE GUESSES ABOUT THE FUTURE OVER FACTS ABOUT THE PRESENT
  14. 14. OVER-ENGINEERING IS WHERE YOU MAKE THINGS THAT ARE SUFFICIENTLY EASY MORE COMPLICATED
  15. 15. YOU WILL QUITE OFTEN HEAR ENGINEERS REFER TO THEMSELVES AS “CRAFTSMEN”
  16. 16. WHEN A POTTER MAKES A POT, SHE TOUCHES IT WITH HER HANDS, AND YOU TOUCH THE SAME PHYSICAL THING THAT SHE DID
  17. 17. USERS DON’T CARE HOW YOUR CODE IS STRUCTURED
  18. 18. IN FACT THEY NEVER SEE OR TOUCH YOUR CODE
  19. 19. THAT’S BECAUSE CODE IS A TRANSITIONAL ARTEFACT
  20. 20. MOZART, PERHAPS THE GREATEST COMPOSER IN HISTORY, WAS HIGHLY PRAGMATIC. HE WANTED HIS MUSIC PLAYED.
  21. 21. OUR CODE IS TO OUR PRODUCTS WHAT MOZART’S MANUSCRIPTS ARE TO PERFORMANCES OF HIS MUSIC
  22. 22. CARING ABOUT YOUR CODE AS AN END IN ITSELF IS LIKE MOZART WORRYING ABOUT HIS HANDWRITING
  23. 23. I QUICKLY GOOGLED “WHY DO REFACTORING”
  24. 24. 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
  25. 25. IF YOU LEAVE HERE WITH ONLY ONE MESSAGE, IT SHOULD BE THIS...
  26. 26. THERE IS NO “RIGHT WAY”
  27. 27. IN FACT, THERE ARE ONLY TWO THINGS THAT SHOULD MATTER TO A PRODUCT ENGINEER
  28. 28. CORRECTNESS REASONABLE MEDIUM TERM PRODUCTIVITY features, perf, security shipping features that users want and improving them thereafter
  29. 29. TEXTMATE
  30. 30. UNRELEASED CODE IS AN INVESTMENT THAT CANNOT PAY OFF
  31. 31. THIS IS WHAT LEAN ADVOCATES CALL “INVENTORY”
  32. 32. YOU GOAL SHOULD BE TO SHIP CODE AS SOON AS YOU POSSIBLY CAN
  33. 33. AND THIS MEANS MAKING THE SIMPLEST THING THAT COULD POSSIBLY WORK
  34. 34. AND SO I COME BACK TO THE PLAGUE OF OVER-ENGINEERING
  35. 35. SOFTWARE ENGINEERS’ OWN ESTIMATION OF QUALITY IS MEANINGLESS
  36. 36. THE QUALITY REQUIRED IS THAT WHICH ALLOWS YOU TO SHIP USEFUL FEATURES AT A CADENCE THAT WORKS FOR THE USER
  37. 37. IF THE QUALITY IS TOO HIGH, THE CADENCE WILL BE TOO SLOW
  38. 38. IF THE QUALITY IS TOO LOW, EVENTUALLY IT WILL BE IMPOSSIBLE TO ADD FEATURES AT ALL
  39. 39. REFACTORING IS WHAT WE DO WHEN ADDING A FEATURE IS HARDER THAN IT NEEDS TO BE
  40. 40. WE REFACTOR SOLELY BECAUSE THERE IS VALUE TO THE USER IN DOING SO
  41. 41. THE CODE WILL BE CLEANER! NO THE CODE WILL BE EASIER TO TEST! NO THERE WILLL BE LESS REPETITION! NO
  42. 42. WE HAVE COME UP WITH VERY ELABORATE SOLUTIONS TO THINGS THAT ARE ALREADY SUFFICIENTLY EASY (BUT REPETITIVE)
  43. 43. COPY AND PASTE IS OFTEN THE BEST WAY TO REUSE CODE
  44. 44. ALL SOFTWARE ENGINEERING TECHNIQUES ARE A MEANS TO AN END, NOT A MORAL IMPERATIVE
  45. 45. SO, LET’S TALK ABOUT THE OBVIOUS OBJECTION TO THIS PHILOSOPHY
  46. 46. TECHNICAL DEBT
  47. 47. TECHNICAL DEBT IS WHERE YOU DO SOMETHING IN A WAY THAT YOU THINK WILL NEED IMPROVEMENT IN FUTURE, BUT WHICH WORKS NOW
  48. 48. DEBT IS NOT BAD! IT’S A WAY OF GETTING AHEAD OF THE GAME IF USED RESPONSIBLY
  49. 49. CORE TO THE AGILE PHILOSOPHY IS THE CONCEPT OF ITERATION. ITERATE: TO DO AGAIN
  50. 50. TODAY’S ENGINEERS WILL GO TO EXTRAORDINARY LENGTHS TO AVOID DOING SOMETHING AGAIN
  51. 51. IT IS A FUNDAMENTAL ERROR TO TRY TO SOLVE A PROBLEM DEFINITIVELY ON THE FIRST TRY
  52. 52. BECAUSE WE DON’T EVEN KNOW IF A FEATURE IS WORTH HAVING UNTIL USERS HAVE USED IT
  53. 53. IT MAKES NO SENSE TO SPEND A LOT OF MONEY GETTING SOMETHING EXACTLY RIGHT WITHOUT KNOWING IF IT’S NEEDED
  54. 54. THIS IS WHY IN AGILE WE USE A LIMITED TIME HORIZON; BEYOND THAT WE ARE GUESSING
  55. 55. ENGINEERS HAVE SCARED NON-ENGINEERS WITH “TECHNICAL DEBT” FOR TOO LONG
  56. 56. HERE’S MY CHALLENGE TO YOU: QUANTIFY IT.
  57. 57. 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
  58. 58. MOST OF THE TIME WE’RE TOLD IT’S GOING TO HAVE DIRE CONSEQUENCES LATER IF WE DON’T DO IT “THE RIGHT WAY”
  59. 59. ARE YOU CERTAIN THAT THE FUTURE CHANGE WILL NEED TO BE MADE? ARE YOU CERTAIN THAT SLOWING THINGS DOWN IS THE BEST OPTION NOW?
  60. 60. BUT THIS PRESUPPOSES SOME PRECISE KNOWLEDGE ABOUT THE FUTURE THAT WE DON’T YET HAVE
  61. 61. SO, NEVER MIND TECHNICAL DEBT LET’S TALK ABOUT TECHNICAL BETS
  62. 62. ENGINEERS WHO WANT TO INVEST IN DOING THINGS THE “RIGHT WAY” SHOULD SHOW WHERE THE VALUE IS TO THE USER.
  63. 63. WHEN YOU CHOOSE TO MAKE A TECHNICAL BET, GO BACK AND MEASURE WHETHER IT WAS WORTH IT
  64. 64. DO NOT FALL PREY TO RETROSPECTIVE DETERMINISM
  65. 65. YOU MAY LOOK BACK AND THINK YOU SHOULD HAVE MADE THE BET, BUT BY THAT LOGIC YOU SHOULD HAVE PLAYED LAST WEEK’S LOTTERY
  66. 66. AND ALSO CONSIDER: EVEN IF I WOULD HAVE WON THE BET, WAS IT THE RIGHT TIME TO MAKE IT?
  67. 67. TO BREAK EVEN ON A TECHNICAL BET, YOU MUST LATER SAVE DOUBLE THE TIME IT TAKES TO MAKE IT
  68. 68. LEARN ABOUT OPPORTUNITY COST The loss of other alternatives when one alternative is chosen“
  69. 69. OFTEN THIS MEANS CHOOSING BETWEEN A USER FEATURE AND A TECHNICAL BET
  70. 70. WE KNOW THE USERS WANT THIS FEATURE NOW. IS YOUR BET GOING TO PAY OFF BIG ENOUGH?
  71. 71. START BY NOT BETTING ON MAKING SUFFICIENTLY EASY THINGS EASIER
  72. 72. EVERYTHING EXTERNAL TO THE PRODUCT - LIKE DOCUMENTATION- SHOULD BE ELIMINATED UNTIL THERE IS EVIDENCE IT'S NEEDED
  73. 73. “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
  74. 74. IT TAKES REAL DISCIPLINE AND THOUGHT TO MAKE THE RIGHT TRADEOFFS FOR A PRODUCT
  75. 75. A PRODUCT IS LIKE A GREAT CITY: NEVER FINISHED, CONSTANTLY CHANGING, ALWAYS ADAPTING TO USE
  76. 76. ASK YOURSELF AND YOUR TEAM: ARE WE OVER PRIORITISING THE FUTURE?
  77. 77. KEEP THINGS SIMPLE, MOVE AS QUICKLY AS YOU CAN, DON’T BE AFRAID TO GO OVER THINGS AGAIN
  78. 78. THANK YOU!

×