Upload
codemotion
View
643
Download
0
Embed Size (px)
Citation preview
QUALITY IS A VARIABLEJames Higgs @higgis
“ We launch valuable products, services and companies that make a measurable difference to the world.
4Studios
200People
22Nationalities
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
MONUMENT VALLEY10,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
INNOVATIVE CLIENT WORKWe partner with smart clients to launch new products, services and companies that are of strategic importance and reliant on innovation.
WE ARE PRODUCT ENGINEERS
EVERYTHING I SAY TODAY WILL BE ABOUT DELIVERING END-USER SOFTWARE.
PRODUCT ENGINEERS SERVE THE NEEDS OF USERS THROUGH THE PRODUCT
YOU WILL NOTE THAT I DID NOT MENTION CODE IN THAT DEFINITION
WE DO THINGS TO MAKE THE PRODUCT BETTER, NOT TO MAKE OUR LIVES AS ENGINEERS EASIER
WE MAKE OUR ENGINEERING LIVES EASIER ONLY IN SO FAR AS THAT HELPS THE PRODUCT
ONE OF THE BIGGEST ISSUES I SEE IN OUR INDUSTRY TODAY IS OVER-ENGINEERING
OVER-ENGINEERING IS WHERE YOU PRIVILEGE GUESSES ABOUT THE FUTURE OVER FACTS ABOUT THE PRESENT
OVER-ENGINEERING IS WHERE YOU MAKE THINGS THAT ARE SUFFICIENTLY EASY MORE COMPLICATED
YOU WILL QUITE OFTEN HEAR ENGINEERS REFER TO THEMSELVES AS “CRAFTSMEN”
WHEN A POTTER MAKES A POT, SHE TOUCHES IT WITH HER HANDS, AND YOU TOUCH THE SAME PHYSICAL THING THAT SHE DID
USERS DON’T CARE HOW YOUR CODE IS STRUCTURED
IN FACT THEY NEVER SEE OR TOUCH YOUR CODE
THAT’S BECAUSE CODE IS A TRANSITIONAL ARTEFACT
MOZART, PERHAPS THE GREATEST COMPOSER IN HISTORY, WAS HIGHLY PRAGMATIC. HE WANTED HIS MUSIC PLAYED.
OUR CODE IS TO OUR PRODUCTS
HIS MUSIC PLAYED.
OUR CODE IS TO OUR PRODUCTS WHAT MOZART’S MANUSCRIPTS ARE TO PERFORMANCES OF HIS MUSIC
CARING ABOUT YOUR CODE AS AN END IN ITSELF IS LIKE MOZART WORRYING ABOUT HIS HANDWRITING
MUSIC
I QUICKLY GOOGLED “WHY DO REFACTORING”
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
IF YOU LEAVE HERE WITH ONLY ONE MESSAGE, IT SHOULD BE THIS...
THERE IS NO “RIGHT WAY”
IN FACT, THERE ARE ONLY TWO THINGS THAT SHOULD MATTER TO A PRODUCT ENGINEER
CORRECTNESSREASONABLE
MEDIUM TERM PRODUCTIVITY
features, perf, security shipping features that users want and improving them thereafter
TEXTMATE
UNRELEASED CODE IS AN INVESTMENT THAT CANNOT PAY OFF
THIS IS WHAT LEAN ADVOCATES CALL “INVENTORY”
YOU GOAL SHOULD BE TO SHIP CODE AS SOON AS YOU POSSIBLY CAN
AND THIS MEANS MAKING THE SIMPLEST THING THAT COULD POSSIBLY WORK
AND SO I COME BACK TO THE PLAGUE OF OVER-ENGINEERING
SOFTWARE ENGINEERS’ OWN ESTIMATION OF QUALITY IS MEANINGLESS
THE QUALITY REQUIRED IS THAT WHICH ALLOWS YOU TO SHIP USEFUL FEATURES AT A CADENCE THAT WORKS FOR THE USER
IF THE QUALITY IS TOO HIGH, THE CADENCE WILL BE TOO SLOW
IF THE QUALITY IS TOO LOW, EVENTUALLY IT WILL BE IMPOSSIBLE TO ADD FEATURES AT ALL
REFACTORING IS WHAT WE DO WHEN ADDING A FEATURE IS HARDER THAN IT NEEDS TO BE
WE REFACTOR SOLELY BECAUSE THERE IS VALUE TO THE USER IN DOING SO
THE CODE WILL BE CLEANER! NO THE CODE WILL BE EASIER TO TEST! NO THERE WILLL BE LESS REPETITION!NO
WE HAVE COME UP WITH VERY ELABORATE SOLUTIONS TO THINGS THAT ARE ALREADY SUFFICIENTLY EASY (BUT REPETITIVE)
COPY AND PASTE IS OFTEN THE BEST WAY TO REUSE CODE
ALL SOFTWARE ENGINEERING TECHNIQUES ARE A MEANS TO AN END, NOT A MORAL IMPERATIVE
SO, LET’S TALK ABOUT THE OBVIOUS OBJECTION TO THIS PHILOSOPHY
TECHNICAL DEBT
TECHNICAL DEBT IS WHERE YOU DO SOMETHING IN A WAY THAT YOU THINK WILL NEED IMPROVEMENT IN FUTURE, BUT WHICH WORKS NOW
DEBT IS NOT BAD! IT’S A WAY OF GETTING AHEAD OF THE GAME IF USED RESPONSIBLY
CORE TO THE AGILE PHILOSOPHY IS THE CONCEPT OF ITERATION. ITERATE: TO DO AGAIN
TODAY’S ENGINEERS WILL GO TO EXTRAORDINARY LENGTHS TO AVOID DOING SOMETHING AGAIN
IT IS A FUNDAMENTAL ERROR TO TRY TO SOLVE A PROBLEM DEFINITIVELY ON THE FIRST TRY
BECAUSE WE DON’T EVEN KNOW IF A FEATURE IS WORTH HAVING UNTIL USERS HAVE USED IT
IT MAKES NO SENSE TO SPEND A LOT OF MONEY GETTING SOMETHING EXACTLY RIGHT WITHOUT KNOWING IF IT’S NEEDED
THIS IS WHY IN AGILE WE USE A LIMITED TIME HORIZON; BEYOND THAT WE ARE GUESSING
ENGINEERS HAVE SCARED NON-ENGINEERS WITH “TECHNICAL DEBT” FOR TOO LONG
HERE’S MY CHALLENGE TO YOU:
QUANTIFY IT.
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
MOST OF THE TIME WE’RE TOLD IT’S GOING TO HAVE DIRE CONSEQUENCES LATER IF WE DON’T DO IT “THE RIGHT WAY”
ARE YOU CERTAIN THAT THE FUTURE CHANGE WILL NEED TO BE MADE? ARE YOU CERTAIN THAT SLOWING THINGS DOWN IS THE BEST OPTION NOW?
BUT THIS PRESUPPOSES SOME PRECISE KNOWLEDGE ABOUT THE FUTURE THAT WE DON’T YET HAVE
SO, NEVER MIND TECHNICAL DEBT LET’S TALK ABOUT TECHNICAL BETS
ENGINEERS WHO WANT TO INVEST IN DOING THINGS THE “RIGHT WAY” SHOULD SHOW WHERE THE VALUE IS TO THE USER.
WHEN YOU CHOOSE TO MAKE A TECHNICAL BET, GO BACK AND MEASURE WHETHER IT WAS WORTH IT
DO NOT FALL PREY TO RETROSPECTIVE DETERMINISM
YOU MAY LOOK BACK AND THINK YOU SHOULD HAVE MADE THE BET, BUT BY THAT LOGIC YOU SHOULD HAVE PLAYED LAST WEEK’S LOTTERY
AND ALSO CONSIDER: EVEN IF I WOULD HAVE WON THE BET, WAS IT THE RIGHT TIME TO MAKE IT?
TO BREAK EVEN ON A TECHNICAL BET, YOU MUST LATER SAVE DOUBLE THE TIME IT TAKES TO MAKE IT
LEARN ABOUT OPPORTUNITY COST
The loss of other alternatives when one alternative is chosen“
OFTEN THIS MEANS CHOOSING BETWEEN A USER FEATURE AND A TECHNICAL BET
WE KNOW THE USERS WANT THIS FEATURE NOW. IS YOUR BET GOING TO PAY OFF BIG ENOUGH?
START BY NOT BETTING ON MAKING SUFFICIENTLY EASY THINGS EASIER
EVERYTHING EXTERNAL TO THE PRODUCT - LIKE DOCUMENTATION- SHOULD BE ELIMINATED UNTIL THERE IS EVIDENCE IT'S NEEDED
“ 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
IT TAKES REAL DISCIPLINE AND THOUGHT TO MAKE THE RIGHT TRADEOFFS FOR A PRODUCT
A PRODUCT IS LIKE A GREAT CITY: NEVER FINISHED, CONSTANTLY CHANGING, ALWAYS ADAPTING TO USE
ASK YOURSELF AND YOUR TEAM: ARE WE OVER PRIORITISING THE FUTURE?
KEEP THINGS SIMPLE, MOVE AS QUICKLY AS YOU CAN, DON’T BE AFRAID TO GO OVER THINGS AGAIN
THANK YOU!