Categories
Archives
Monthly Archives:
March 2007
Introducing : ShuffleStack
Andy Lewisohn, one of our rockstar Flex coders, just put together a really slick solution to a very common problem. We often contend with large amounts of information that vie for attention on our apps' screens, and reusing the same components time and again just doesn't always work. Over in the lab, Andy shows us ShuffleStack, a Flex component that tackles this problem in a better way.
Permalink | Comments (4) | TrackBacks (1) | Technorati Tags : lab arc90 flex card stack
Posted on March 02, 2007 by Chris LoSaccoSoftware as Art
Why is building software often compared to bridge building?
In college, I took an advanced Comp. Sci. elective called Software Engineering where the analogies to construction were many and, seemingly, widely accepted. And I agree, in large part, with these parallels. There's a lot of overlap between the two realms.
But I am increasingly finding that really successful, groundbreaking, go-where-no-software-has-gone-before kinds of products are sprouting up around the philosophy that software is more an art than a science.
What evidence is there to back this claim? I would suggest that there are a few items about software which separate it from its more physical constructed counterparts; this is not a new idea. But in my mind, there's one reason paramount to the others.
Software can change. When I build a bridge, I know I'm done when there are cars driving over it every day. Users interacting with an application does not imply any sort of finality about completion. It's an inherently "scoped" process - the bounds around a project are decided up front (or sometimes not) and arbitrarily enforced - because the end result can change relatively easily on a whim. Tweaking a line of code is quite different from, say, moving a staircase two feet to the left.
And so I find it intriguing that the art of building software isn't about realizing a blueprint, about finding that endpoint where the cars are driving over the bridge. It's about embracing change, writing magnificent code that feels right, creating an application that appeals to us on a deeper level.
A great example of this kind of development is the new wave of chess-playing programs that discover incredibly insightful techniques which have eluded generations of grand masters. Our first crack at intelligent chess was brute force - just figure out all of the moves, already! - but the sophisticated programs that have evolved use subtle logic and best-guess approaches to produce playing styles that even their creators didn't (couldn't) imagine.
This sort of thought process makes sense to me on an intuitive level. Writing code isn't an act completely free of constraint, of course, but some of the best artistic expressions have come under heavy constraints (perhaps Shakespeare's use of iambic pentameter, or Picasso's blue period, are good examples). Elegant, artful solutions to complex problems have a sort of intrinsic appeal.
I think that the future of software is in these strategies and methodologies, the ones which cast software development as an artful process rather than an engineering one. Clever and creative products, both in interface and in code, are attractive! And popular. And successful. There's little doubt that we, as creators and software professionals, should be doing all we can to
So let's starting thinking about software as art, and not as bridges. I'm willing to bet some great stuff will happen as a result.
Permalink | Comments (3) | Technorati Tags : software design art architecture construction
