How applications learn. What happens after they are built?

I have been reading Stewart Brand's much celebrated book over some time now. Took some inspiration from it for a local KM-community talk on innovation. In particular, I was tickled by his characterization of how ideas spread:
Perhaps culture is driven by just such flea-market ideas in a vast network of uncredited influence.
Replace culture by 'innovation in software' and it still makes perfect sense. Our aggregated blog page is a good example of a flea-market of ideas.

Stewart argues for evolutionary design over visionary design - now where have I heard that before? It seems he once suggested to an architect that he go back to his building to see how the users were finding it. The architect said, "Oh no. You never go back. It's too discouraging." Just reinforces that we need to be on our guard when we choose technologies to build applications. Will the eventual maintainers of the application be comfortable with them? Is the app designed for change? Does the roof (read abstractions) leak?

It's true that construction industry (or any other industry for that matter) isn't a good analogy for software development. In particular, coding is not analogous to construction (compilation probably is). But the life of a building seems to have striking similarities with that of an application. Though buildings are expected to have much longer lives than applications, the total churn that they are subjected to is probably comparable. Buildings are subjected to form-over-function pressures of the marketplace - software apps are less so. Both suffer every now and then from architect hubris.

Wired covered the book long ago. The BBC documentaries based on the book are still available.

Part 1: Flow
Part 2: The Low Road
Part 3: Built for change
Part 4: Unreal estate
Part 5: The romance of maintenance
Part 6: Shearing Layers

There is also a good summary up at:

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.