• Prof. Craig Thompson, Acxiom Database Chair in Engineering at the University of Arkansas and one of the Corba object architecture's authors, premiers Architectural Perspectives in the current issue (see p. 83). The column will provide a platform for Thompson's ruminations on the future of the Internet and pervasive technology.
• Genevieve Bell, an anthropologist at Intel working on bringing the human component into discussions about technology, will introduce Field Notes in the March/April issue. Bell's column will focus on the intersections of cultural practices and emerging technologies.
• It might be clear what a software system has to do, but it can still take a lot of energy to make it happen. MER/CIP required only a little in the way of novel algorithm development. It did not demand solving any unsolved computer science problems (that is, "here's where the artificial intelligence goes"). There weren't really any major surprises in system creation. Nevertheless, it took about a dozen programmers about two years to build the system.
• System development is less and less about coding than about using things and gluing them together. Knuth has observed that literate programming today is literally thumbing through 10 manuals as you code. This is a stark contrast to my Knuthian education of 30 years ago, where the heroic programmer wrung every efficiency into the smallest data structures and tightest loops. Correspondingly, the headaches in system development have moved from finding your own bugs to discovering the actual behavior and limitations of other people's products. (These days, it might be more valuable economically to be knowledgeable about a product like Oracle or WebLogic than to have the skill to build a relational database or application server.)
• Building a novel system means that what you want to build changes. Create a flexible enough architecture to allow for this. In building individual components, look for ways to make them data-defined rather than code-defined. For example, the MER/CIP code that searches the file system structure for interesting new files profited by making richer descriptions of "interesting" in the configuration data. (In general, move as much as you can out of code and into configuration.)
• Building a novel system means that customers will not be able to elucidate at the start what they want; only by using the system will they be able to tell you what you should have done.
• No matter how many design meetings you had with your future end users, they will use your product differently than you had anticipated, and they will make assumptions you never expected — or even that you explicitly denied.
• System development would be easy were it not for optimization. Much evil and many faults arise not from trying to perform the desired task, but from trying to perform it more efficiently.
• System development would be easy were it not for dealing with failure. This is particularly true of distributed systems where, as Leslie Lamport has observed, the failure of a component that you didn't know existed can cause your system to fail. In real systems, things don't work as planned or promised. You must be prepared for that possibility.
• You don't need extended evolution to create a usable user interface. Perhaps in credit to the user-interface developers, the overall structure of the MER/CIP interface and its implementation details converged fairly quickly to a workable (though not perfect) organization. (Of course, it might help that the users are rocket scientists).
• It is possible to create systems using a far more bottom-up process than perhaps expected. The use of protocols and interfaces allows more independent component development than classical software-engineering theory would recommend. The software development proceeded smoothly — even through changes such as going from browser-based applets to fat clients (applets take too long to load and don't give enough control over the interface) and from Java RMI to Web services (system administration having decided that open sessions are insecure).
• You don't need an elaborate, formal modeling activity before coding. (I'm not sure this one quite fits into "obvious but not true," since I never believe it anyway.) Early modeling would have turned into archived lies.