Constants aren't, variables won't

We like to think that standards are fixed and unchanging. Yet they shift and change over time, like sands on the shore.

Hardware has certainly changed. In fact, it has changed so much that today's PCs share nothing with the original IBM PC. Take any part of the today's PC and you find that it will not connect or attach to the original IBM PC. The keyboard is different (USB was not available on the IBM PC), the display is different (the IBM PC had monochrome or CGA, not VGA and certainly not DVI), the internal cards use a different buss... the list goes on.

The software platform has changed, too. From DOS, to Windows 3.1, to Windows 95, to Windows NT, and on to Windows XP and now Windows 7. While some early PC programs still run under Windows 7, no one uses them for serious work.

Development tools have changed. Original PC programs were written in assembly language. The early versions of Windows used Pascal. Later versions used C and then C++. Now The dominant language is C#.

Our standards change. Our tools change. With this environment, we must adopt development practices to accommodate change. Yet too many shops treat systems as fixed solutions: define the requirements, build the system test it, and release it. They allow for defect corrections and enhancements (often called "maintenance") but they do not plan for changes to platforms or tools. Instead, they wait for new platforms and tools to become dominant, and then they rush to bring their system to the new environment. People rushing and working under pressure to mutate a system into a new form; the results are often dismal.

Forward-looking shops will prepare for change. They will encourage people to learn new technologies. They will strive for clean designs. They will monitor changes in technology and tools. They will look outward and observe others in their industry, in other industries, and in academia.

One does not have to predict the future precisely. But one must be prepared for the future.