Dan Bricklin's essay on software that lasts 200 years reminds me of s similar idea from Ward Cunningham on software lifecycles...
First, the notion of a program life cycle admits failure from the start. If we are to have a life cycle, let us make it long. One hundred years cannot be beyond reason. Second, analysis as an activity to be conducted independent of implementation [see correspondence] again presumes implementation artifacts to be short lived and of little value. These ideas have become self-fulfilling prophesies. Although they apply in the current circumstance, they have become barriers to change from that circumstance. They impede progress in object-oriented programming.Of course we want and embrace change if for no other reason than that change is inevitable. So a great component of a realistic response to these challenges will be addressing what it may mean for software to both *last* and *change* at simultaneously.The cause of flexibility will not be served by merely discrediting life cycle or independent analysis. To make progress we must examine the system of practices that have lead to these principles, discard those practices justified only by habit, construct new practice where human nature alone is insufficient, and then describe the whole with metaphor that implies useful longevity for the programs we make.
1 comment:
It's the rules of human behavior, of desire/needs, of memory/cognition, of hardware limitations, of prior content and its storage medium, and of the world's ontology that will last. This is more content and modeling than the code itself.
Algorithms that extract new information and move that information around will last.
The rest are just shortcuts/tricks that will fade away. Or rather, they are like conversations where the echo of the sound of our words fades away but the memory of them will last and the repetition of them in another form will be spoken again by others.
Post a Comment