Every week at DesignAxiom has teachable moments. A small discussion draws a third person, then a fourth, and before long we all put down what we’re doing to open the floor. I often lead, but it’s an open forum.
These are the moments that have helped us define our practice. We hold issues up, look at them from different sides. And then do a trial close: “OK, so from now on, we’ll do it this way?” The question hangs in the air. That’s when the quieter voices will offer some dissent: “Hmmmm, I dunno, what about X?” The discussion starts again.
Any issue is a candidate: ActionScript questions. Client issues. Visual design questions. Product announcements. And xkcd comics.
I don’t know what management philosophy this comes from, but it works for us, and what’s better, it feels right. Once a decision is made (sometimes by consensus, sometimes with me laying down the law), I rarely have to act as an enforcer. The team police themselves with a combination of “gotcha” messages and pointed humor. For a while, severe violators were sent with mock-seriousness to the “wall of shame”–their picture and crime tacked onto our internal wiki.
Victories are celebrated too: “Good thing we had all those view controllers. This would have taken twice as long otherwise.” (For the record, view controllers are a part of our internal application framework and they are both despised and loved, despised because view controllers are where all the complexity and timing issues occur in interactive apps, and loved, because the alternatives, any of them, lead to disaster.)
This is an approach to technology (and business) that is grounded in experience and actual observation–not marketing or dogma. We are neither swayed nor cowed by marketing announcements or breathless testimonies about new techniques or technologies. We adopt what works, and stop doing what doesn’t work.
Only what really is and what really works concern us.
“Freedom from hope and fear is the stoic ideal.” — that’s from Matthew B. Crawford in his book Shop Class as Soulcraft. A book, by the way, that every software developer should read, if only to discover that your job is more motorcycle mechanic than computer scientist.
When we see a new release of Flash or Flex from Adobe, we damp down our hopes for the new features knowing that they will inevitably fall short of expectations. Almost every new version of Flash and Flex comes with a completely re-engineered set of user interface components. The inevitable disappointment doesn’t sting because we are unafraid to build all of our own components, which, by the way, are based on an uninterrupted evolution of code over seven years now.
When we see another claim that HTML5 or Silverlight will “kill” Flash or replace it, we’re neither afraid (because only time will tell and it will certainly not be this year) or hopeful (that finally, the whole world will begin to demand the kind of user experience we can build–won’t happen, ’cause it matters to some, and not to others).
We are, in a word, stoic.
How did we get that way? Well, I think a look at my experience in software and interactive development is a good place to start. Don’t worry, this isn’t going to be a résumé. At least, not one you’d send to an employer. And it will lay the groundwork for what I want to say about Flash, our industry, and Apple’s latest moves with the iPhone and iPad.
Stay tuned.
