Re: What Not to Build

Stephen Downes has written another winner. The putative audience is technology developers, but anyone interested in educational change would do well to read What Not to Build. Downes begins:

So, here is my advice on what not to build. Actually, it’s a bit more that that: it’s a list of what not to build, a list of some things that people are working on now, some fads to avoid, and some indication of what’s out there for the taking, if you can get your act together in a hurry. And what lies beyond that? The domain of real innovation and progress.

I left this comment on Stephen’s post:

Here are just 2 quick points.
1. “How” is just as important as “what”. There’s a parallel to What Not to Build that might be called How Not to Build.
2. There’s one feature of the web that nobody has come close to solving. That feature is it’s monstrous size and it’s pulsating rate of growth. For example, consider search. Google Search is woefully inadequate in the face of the web’s size and growth rate. Alternatives like the federated searches (eg, on science.gov) are better but still provide inadequate coverage and features. There must be a hundred or more companies in the search business, and I’m certainly not suggesting that anyone create another one (this might be worse even than building another OS). But the web desperately needs some kind of middle layer of data systems that can be used by ordinary people. I’d say that the major entrepreneurial and socially constructive opportunities await builders of the web infrastructure.

In some ways the web today parallels the situation with enterprise databases several decades ago. It was easy to put data into these relational databases, but it was dreadfully difficult to get reports, analysis, and information out in any useful form. Development work proceeded along two fronts: i) creating reporting and analysis tools that simplified the user interface and seemingly made SQL unnecessary; and ii) creating a middle layer of data abstracted from the full complexity of the relational databases but with a simplified architecture so that the new tools would actually work.

Google search and other current web search tools are over matched by the complexity of the web, just as reporting and analysis tools were once over matched by enterprise databases. I suspect that it will take a similar architectural change to make the web truly useful. But this is not going to come easily. It was devilishly difficult with enterprise databases, but at least developers had SQL as a query tool that could uncover even the most inaccessible of the data. There is no equivalent query language for the web, so simplifying the web architecture for ease of use will be orders of magnitude more difficult than enterprise databases. It’s possible that the semantic web may eventually play this role, but I’m not very sanguine that it will happen any time soon. We need something that will work today.