May 18th, 2015
What a year has it been for Territory Studio and its founder David Sheldon-Hicks. It’s only been nine months since our interview about the studio’s screen graphics work on “Prometheus” and “Guardians of the Galaxy”, and in the meantime Territory’s work has graced the big screens on three major motion pictures! In this interview David talks about exploring the technical and human aspects of advances in the field of artificial intelligence in “Ex Machina“, the futuristic interfaces of the alien universe of “Jupiter Ascending” and the vast screen graphics canvas of “Avengers: Age of Ultron“. He touches on the collaboration with directors and production designers to distill and refine the visual language of the interfaces, the process of rapid prototyping in the pre-production phase and the tight back-and-forth adjustments of on-set playback sequences, and the technical aspects of projecting interface sequences on translucent glass screens. In the last part of the interview David takes a deep dive into the world of virtual reality interfaces, ranging from enhancing cinematic experiences to better leverage of content in our everyday work and leisure scenarios.
Kirill: Last time we spoke about your studio and its earlier work. And in the meantime you’ve had Jupiter Ascending, Ex Machina and Avengers: Age of Ultron come out, with a lot of work that you’ve contributed to these productions. And on top of that, you’ve started exploring the world of virtual reality.
David: We actually worked on Jupiter Ascending a year prior to that interview. The project took a while to come out (6 Feb 2015) so we haven’t been able to talk about it up until more recently.
Kirill: How does it feel that you have this pile of work that you’re sitting on and can’t tell anybody about?
David: In some ways it’s really frustrating, especially for the people in the studio who have worked on it. But, we’ve all signed NDAs, and don’t want to ruin it for the fans by saying something that might spoil the story.
Yet, it is quite nice to have a bit of time to prepare our portfolio and showcase, to fully do it justice in terms of the story behind all the work. When you’ve just finished a film, you’re so exhausted and still in that space. Sometimes it’s hard to look at the project objectively and fully appreciate all of the thinking and the ideas that went into it. When you have space and time – around six months or so ideally – you get enough distance to join up the dots between the deliberate and intuitive.
This gets really interesting when it comes to our approach to technology in a film like Avengers. By reflecting on how the script and story points influenced our research, we can sometimes see how quickly perceptions and expectations around innovations evolve.
Looking back we can see how public opinion regarded a piece of technology at the moment we were making the film, and how it changed over the 6 or 12 months leading up to it’s release – and hopefully we’re not behind technology!
Kirill: Does it worry you that the world of consumer technology is evolving so rapidly around us in that regard? Can your work quickly become outdated?
David: As a user, yes, because it’s hard to keep up sometimes. But as far as the work being outdated, in some ways we have to celebrate that. We play on the fact that it’s a film of the moment that reflects the cultural experiences of that point in time. It’s not just about the technology, but also about what the technology says about us as a culture. And I’ve always loved that about unashamedly 80s movies. For example, the idea of hoverboards in “Back to the Future” reflected our cultural expectations that skateboarding, so huge at the time, would exist in the future.
So the idea of a date stamp is not such a bad thing. If a film does date because of its views on technology, it can be quite enjoyable. And there’s an element of nostalgia in that, perhaps ten years into the future. You look back on it with fondness the same way you’ll look back at your current iPhone 5/6 when you’re holding your new iPhone 20 or whatever it might be.
Of course, there are other ways to explore technology and different films date in different ways.
In Ex Machina, Alex Garland [writer and director] was more interested in near-future thinking rather than techno-fantasy. He had done a lot of research around AI for the film to keep the story grounded, and we also undertook a lot of research into UI and UX in terms of where the technology is going. So our work in that film reflects the evolution of user experience towards simplicity, personalisation and ease of access, while it also reflects the narrative layers in the story.
Embedded just underneath the lovely uncluttered UI is access to programming code: we wanted it to feel that Nathan had created this OS for the benefit of the public, yet always kept close to the code, and could easily access and manipulate it.
BlueBook office browser software in Ex Machina. Courtesy of Territory Studio.
So, while the work that we delivered made a loose statement on where UI and UX are going, it was also a technological window into narratives playing out around the film – a narrative device for the characters to monitor the activities around the building, for example.
I’m sure Ex Machina will date in a slightly different way other films of that genre because its focus is not to comment on future technology and it’s not tying itself into the cultural zeitgeist in terms of style. As a film about the thinking around AI and our relationship to technology at this time, it’s less a statement about aesthetics and more of a timeless piece.
Ex Machina screens still. Courtesy of Territory Studio.
Read the rest of this entry »
May 13th, 2015
People come and people go. But the code base stays there. It evolves over time, like an amorphous organism. It mutates (or is, rather, being mutated) to meet the changes in its environment. Some of its parts don’t always function as expected, requiring a surgical procedure to try and set those parts on the right path. And if you’re not careful, it can swallow you whole and nobody will hear from you ever again. Analogies. They always break apart at some point.
Last December marked my fifth anniversary on my current project. The codebase has been there before me (perhaps a year or a bit longer), and since then it has seen significant changes. I doubt that there’s any single line of code that has survived untouched in all that time. Some modules have been rewritten completely. Some have been rewritten completely more than once (hello local app history management). Certainly none have remained in their original form or function as we’ve moved through multiple rounds of redesigns that were (almost always, hello all things Material) driven by evolving business requirements.
And beyond all the feature changes, there are always bugs. Sometimes they are in my code. Sometimes they are in this code that this other person wrote, and it just so happens that they are half way across the globe enjoying their vacation just as we’re closing down on this year’s I/O and seriously who does that. OK, that was too specific. And sometimes bugs happen to be in the module that was last touched by this guy who’s no longer on the team and not even any longer at the company.
Clarity and brevity are your only  two weapons to help you wade the murky waters of code that is not old enough to be completely replaces but not young enough that you can actually remember either writing or reviewing it. Complexity, on the other hand, is your worst enemy. Back to analogies!
Complexity is an affliction that attaches itself to this one part of your organism. And it’s not going away on its own. Next time you’re in that module, fixing a bug or extending the functionality, that complexity winds itself into the new code, spreading just a little bit farther in. And then it intersects with another affliction that originated in another part of your organism. At the time, both afflictions were pretty local and pretty small. But they were left unchecked, growing just that much bigger every single time somebody touched things around them. And now they are intertwined.
And at some point you have that thing in your organism that everybody’s afraid to touch. Nobody has any idea how to make it better. Nobody has any idea what side effects a specific surgery (aka bug fixing) will have. It might have taken you a couple of hours at the beginning of the next release cycle to go back and treat that original affliction because you just didn’t have enough time to be clear and brief. But ain’t nobody got time for that. That’s not glamorous work. That’s not work that you put up in your promo packet. That is work that can only be appreciated by people who have spent at least a few years on the same code base.
Complexity is by far our worst enemy. Well, that and software patents. But that’s a whole another subject.
May 6th, 2015
In the last post I talked about deliberate brevity – taking time to think through a problem and finding a solution through concise coding. But writing as little code as possible is most certainly not my goal these days. In fact, as a goal unto itself it sets you onto a very dangerous path.
Estimating roughly, I spend 10% of my time writing code and 40% of my time debugging it (including code written by others before me). Let me repeat that again. I spend 4x as much time reading and tweaking existing code than writing new code. I’m not that interested in writing tersely. I’m much more interested in writing clearly, for the benefit of everybody that is going to be looking at that code down the line – future me included.
At times we are faced with complex problems. It’s only natural to come up with complex solutions. Complex solutions create an illusion of being a master of your domain, impressing your peers and beefing up that pitch to bump you up to being the “senior engineer, level 5C” for the next promo cycle. “Nobody knows that module better than Bob. In fact, Bob is the only one who understands it at all.” I’ve seen enough code written by Bobs. To be honest, I don’t like where the Bobs of our world are taking us.
It takes time and patience to distill a solution to its most vigorous form. And it takes skill and humility to remove complexity from the solution. To practice the craft of writing clear code. Code that is clear to read, clear to maintain and clear to evolve. Finding clear solutions to complex problems is the ultimate mark of our craft. It’s time to stop admiring complexity and start appreciating clarity.
April 29th, 2015
I’ve spent four days at the beginning of March this year working on immersive hero images in our app. I touched around 250 lines of code all in all, mostly adding new code but also modifying or deleting a few dozen existing lines. And that’s pretty much all I did in those four days. Sure, there were a couple of small meetings here and there and an occasional code review, but overall I’d say that I’ve spent at least 8 hours every day working on this feature. Overall my total output was less than eight lines of code per hour. That sounds not very productive of me, I know.
Recently I find myself not really writing a lot of code. Instead of diving straight into the editor, I think. And I think. And I think some more. I literally sit there staring at my desk. I get up and walk around the room. I take a break and browse the web (but don’t tell my managers about that). And then I push it out to the next morning.
On any given day I find myself spending, perhaps, 10% of the time writing code, 40% of the time debugging it and 50% of the time thinking about it. It certainly seems like a big waste of my time. I should be down there in the editor, banging out line after line, method after method, class after class, throwing it at the device and seeing what’s happening. You know, walking the walk.
But I’ve walked that walk before. It felt good to always be moving and it felt great to always be moving fast. These days I prefer to move slow.
I like to think about this as deliberate brevity. A long long time ago, a French mathematician and philosopher Blaise Pascal said “Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.” Translated loosely, “I have made this longer than usual because I have not had time to make it shorter.”
I enjoy taking time to make my changes brief and vigorous. In the words of William Strunk, “When a sentence is made stronger, it usually becomes shorter. Thus, brevity is a by-product of vigor.” I believe that every line of code needs to fight for its right to exist in our code base. I believe that every comment needs to fight for that right as well. I immensely enjoy code reviews where one of my teammates points out how I can cut out even more code and make things even simpler, but without losing the overall clarity of what the code is doing.
I am indifferent to productivity tools in general and to debates on which IDE makes programmers more “productive”. When you spend five times as much time thinking about the code than writing the code, the number of shortcuts, templates and auto-completion becomes quite irrelevant. I don’t measure my output by words of code per second or lines of code per minute. I measure my output by the robustness of the path I’m paving, over weeks, months and years.
When you spend half your day thinking about the code, every distraction hurts. Open office plans that proclaim to foster spontaneous exchange of ideas are creating a never-ceasing cacophony of distractions that is actively disrupting the most precious resource we have to offer our employers – our brains. Until they come with a thinking-time switch that envelopes you in a literal cone of silence, they must not progress beyond the corporate facilities planning spreadsheets. I realize that it’s a bit late for that.
Don’t aim to impress me with how fast you can churn out new code. Don’t tell me that it will all be done by the end of business day. It rarely happens, and when it does, I know I’ll find myself wading through vast reams of that code in a year’s time (when you might have already gone to some other project), trying to understand why it is, in fact, so vast. Don’t ask for permission to spend time thinking. And don’t think that spending all that time thinking only to write fewer lines of code makes you a less productive programmer. Be concise. Be brief. Be vigorous.