Posts Tagged ‘software’

The Silicon Valley “Bubble”

by Hang

A lot of people are rightfully worried about the “bubble” that exists around Silicon Valley. In the two weeks I’ve spent immersed deeply in the Bay Area culture, this is the best way I’ve found to explain what’s actually going on:

In the valley, people are willing to adapt their behavior to fit the software.

Everywhere else in the world, people adapt the software to fit their behavior.

Let me explain through an example: One of the things I talk a lot about is how corporate shared calendering systems suck because they’re all built according to a list of features without a consideration of the narratives that people are wanting to express through them. Everywhere else in the world, when I’ve discussed this, people join in the gripe and tell me crazy stories of their own about socially tricky situations made awkward due to shared calendering systems. It’s only in the valley where I tell people this and they go “That’s not a problem for us, we adopted this corporate culture which means our shared calendering system doesn’t suck anymore”. Let me repeat that again for emphasis:

We turned our entire corporate culture upside down to accommodate the whims of a piece of software we wanted to adopt.

That’s crazy. Absolutely, bat shit insane crazy and that’s what’s made the valley such a great place to build software. The valley is uniquely able to take a piece of software in it’s rough, early adopter phase and figure out how to mold their lives so that this software becomes useful. This is the classic early adopter pattern and it happens to people everywhere around the world but only in the valley is it a cultural norm and you’re looked at weirdly if you’re not willing to join in. It’s only in the valley where I’ve met companies who now have their entire corporate philosophy centered around being OK with you publicly declaring that you’re going to take a nap in your office and that you should not be disturbed solely because their shared calendering system didn’t have the effective privacy controls necessary to navigate that tricky social dance.

This attitude is so pervasive and so normal within the valley that it’s taken an outsider like me to come in and point out to people how goddamn weird that is. When I put it the way I do, people get pretty disturbed and rightly so. Because, while the valley is a uniquely great place to be building software, it’s not a great place to be designing it. Over and over again, I’ve encountered the pervasive attitude of “Well, the average user will just have to make this fundamental shift in the way they conduct their lives and it’ll be great. They’ll do it because the benefits will outweigh the costs”. That companies don’t understand on a gut level how unrealistic such a statement is for anyone living outside of the valley is, IMO, the primary cause of failure for startups that never manage to move out of the valley.

I really don’t know what the solution to this problem is except to become acutely conscious of it and to fight that impulse at every turn. There’s a certain ambivalence I have towards moving to the valley as a result of this, this visceral fear of being digested by the valley process and emerge the other end as a pod person. A year ago, the last time I was planning to move down here, I don’t know if I would have had sufficient life experience or insight to articulate the pattern that happens in the valley. If were to avoid the valley for another year, who knows what insights I’d be able to articulate then that I’m still not able to articulate now?

Software as a backdrop:

by Hang

We must first recognize that what a town or building is, is governed, above all, by what is happening there. […] Those of us who are concerned with buildings tend to forget too easily that all the life and soul of a place, all of our experiences there, depend not simply on the physical environment, but on the patterns of events which we experience there.

– Christopher Alexander, The Timeless Way of Building, p62

Software is not about code, it’s about experiences. It’s about people doing things. Your software should serve as a backdrop to this, an enabler and a force multiplier. But keep in mind that software is never the center of the show.

Stop thinking about your product in terms of code, in terms of technology and features. Instead, your software is stories, it’s actions and people doing stuff. If you haven’t got people doing stuff, then you don’t actually have software, just a bunch of bytes sitting on a server. When people change the stuff they’re doing, your software has changed.

As a designer, you need to be always mindful that you’re designing spaces, it’s up to the users to inhabit them.

July 23 2008

The right size for the job

by Hang

Being a computer scientist by background, one of the things which I’ve always been keenly aware of is issues of scale, not only of computer systems but also of human systems. As organisations grow larger, layers of beaurocracy and organisation are needed just to keep things on track and get the job done. When done well, each of these things has a clear task and purpose but they also involve an inevitable tradeoff of time taken away from actual production.

One of the challenges I’ve been facing establishing policy at this early stage is what formal procedures and mechanisms should we put in place to safely navigate between the twin pillars of informal cowboy style development and rigid, stifling control freak management. At the moment, my inclination is to lean towards slightly too much procedure over slightly too little because I’m also treating this phase as a learning experience.Part of the reason to implement these systems is so that we can learn to use them and be familiar with them and understand the individual nuances (aka: frustrations) of each one.


Copyright ©2009 BumblebeeLabs — Theme designed by Michael Amini