Quality is a variable

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!