(or, how I learned to stop planning and become a slow programmer.)
Most programmers will have a structured approach to software development, probably involving a framework of modular code that lends itself well to a process of constant refinement. This means that changes can be made to the program very quickly and easily, and would generally be considered good coding practice. The management process of software development can learn from this approach, by being open to new ideas of what exactly the software will be used for.
This is basically what I was working towards when thinking about adaptive architecture. In fact, what I’ve been thinking about in relation to programming doesn’t really have much to do with writing code (although the style of coding would be directly influenced by the general approach, and necessary to it’s success), but more to do with the philosophy behind the code. That is: let go. Enable, don’t control.
In the same way that the ethos of adaptive architecture accommodates individuals’ interpretations of the function of a design, Adaptive Software design expects that users won’t always play along with the script. The software developer needs to be prepared to relinquish control of the software and definition of it’s function to the user.
An example of this at work is the evolution of Flickr, which started out life as an online multiplayer game. When one aspect of the site became more popular than all others, and visitors used the program as a photo-sharing facility, the developers ditched their original idea and went along with the popular momentum:
User feedback also drove a lot of the decisions about features. We had user forums very early on and people told us what they wanted… But we also have a very agile development process. We deploy code to the site maybe 10 times a day on a busy day. And we’re constantly adding new features, small and large.
Not only is the system flexible enough facilitate a two way relationship with it’s users, but the whole architecture of Flickr is already open enough to allow users to reinterpret it’s function without new features having to even be deployed. Here are some photos on Flickr tagged with 4sale; some people are now using Flickr as an online auction site. Here’s someone using Flickr as a movie blog. All the Flickr developers have to do is not interfere, and a new community of users creates itself.
Adaptive Software development means admitting that your users might know more about how they want to use your software than you do:
Through the Internet, people are discovering and inventing new ways to share relevant knowledge with blinding speed. As a direct result, markets are getting smarter—and getting smarter faster than most companies.
I’m working with a designer from Cornwall on a software project, and we’re trying to implement some of these ideas. By publishing the software iteratively, and workshopping with groups of users, we’re hoping the tool will grow organically to meet a need that hasn’t been fully identified yet. She’s calling it ‘slow software’ (after the Slow Food movement), wherein each function of the tool gradually evolves to become more useful to it’s community of users.
It’s a mindset that’s about pull not push; bottom-up not top-down; organic not synthetic; evolution not stagnation; adaptation not restriction.
Some references: