Posts Tagged ‘software’

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.

(more…)

Copyright ©2009 BumblebeeLabs — Theme designed by Michael Amini