In a discussion at XML DevCon 2000, a panel of experts discussed the future of software development. They concluded that XML and the Internet were fundamentally changing the structure of applications and that, "You still have to write code."

Moderated by conference chair Ken North, the panel consisted of Paul Brown of Informix, Tim Bray of Antarcti.ca, Peter Coffee of eWeek, author Kevin Dick, Jim Gray of Microsoft, and Norbert Mikula of DataChannel. Discussion centered on changes to databases, transactions, security, wireless devices, and the software development process itself.

In answer to the assertion that databases were dead, Brown disagreed strongly. Databases still provided fundamental services such as saving data to disk and answering questions. What was changing was the nature of databases themselves, noting that the fastest growing database today was Gnutella -- essentially a large, distributed database.

Also changing, said Gray, were transactions, which North noted were not even understood in some sections of the e-commerce community. In classic transactions, data is not committed to the database until the transaction is complete. Due to the loosely coupled nature of the Internet, this model often doesn't work. Instead, data can be committed before a transaction is complete, leading to an inconsistent view of the data. Instead of the ability to roll back transactions -- that is, pretend they never existed -- each action has a compensating counteraction.

To illustrate, he described an invoicing process in which a provider bills a customer and, if the customer doesn't pay, bills them again and again. This violates the classic view of transactions in that the provider has often already provided a service even though the customer has not paid. That is, the data is not consistent even though the (computer) connection between the provider and customer has already been closed.

Dick compared this to the difference between Newtonian and Einsteinian physics. In the former case, there is a consistent view of the world; in the latter, each observer is allowed to have their own view. He also noted that if different observers can't resolve differences their views -- that is, the customer doesn't believe they need to pay the bill -- a third party is needed to resolve the dispute.

Switching topics, North asked how many in the audience expected to be doing B2B in the next year. Fully fifty percent raised their hands. Didn't this, North wondered, raise security issues? Dick answered, stating that his flip answer was that, "XML is too secure." His point was that a tremendous amount of security technology already existed and that virtually all of it could be applied to XML. Furthermore, the structure of XML documents meant that it could be applied on an even finer scale than for unstructured documents. For example, a given document fragment could be signed or access could be specified on a per-element basis.

The latter statement made Bray's "blood run cold." In his experience, overly complex security models actually lowered security due to greater opportunities for human error during implementation. Dick agreed, stating that the simplest possible model should be used, even if this did not lead to an ideal solution. Coffee somewhat disagreed, pointing out that information is crossing more boundaries than ever before, which unfortunately necessitated more complex models.

Also popular with the audience were wireless technologies, which about one third expected to support in the next year. While XML's separation of presentation from content was expected to help here, Dick noted that total separation was often very difficult to achieve in the real world.

Also unclear was who would actually determine presentation. Coffee stated that an earlier panel discussion he had participated in felt that clients had enough intelligence to determine how to display data themselves. This would not only reduce work for the server, but also avoid problems when new devices were added to the system.

In an interesting comment, Brown pointed out that the question was not necessarily how to present the data, but what to do with it in the first place. As an example, he thought that it was a mistake to view cell phones as browsers. A better example of how to use wireless technology was one mentioned earlier by North, in which Heineken had a server into which you could enter GPS coordinates. The server would return the location of the nearest place to buy a Heineken beer. Although the application itself was somewhat fanciful, it illustrated well both the diversity of applications that might exist in the future and the technical problems involved in implementing them.

The discussion closed on the topic of software development: was it really getting any easier? As Bray had noted earlier, XML has been hyped as the solution to all problems but that, at the end of the day, it's just an information transport and that, "You still have to write code."

In response to a question on code reuse, Bray said that the net amount of code being written hadn't really decreased. This might be true, agreed Coffee, but code was being reused, which meant that programmers were doing more work than ever before. It was, he said, not "a failure to achieve reuse, [but] a triumph of productivity."

The case was best stated by Gray, who tries to spend two hours a day writing code. Not only did he think that reusable components and better tools make him much more productive, he also noticed something unthinkable ten years ago: the kid across the street could write a Web site.