« May 14, 2003 | Main | May 16, 2003 »
May 15, 2003
eGovernment Like its 1994
Dave Fletcher also reports that the Utah State Legislature has made district profiles available online. Bless their hearts, they try to get this eGovernment stuff, but they're just not with it enough to do a good job and their too proud to ask for help. So they end up with a site with some great information on it that almost entirely unusable. Why in the world wouldn't you make it easy, inside this application, for someone to identify their legislative district. This also seems like the kind of information that ought to be in HTML, not PDF. I fear that this is one of the huge challenges of eGovernment that is largely ignored: there's not one reason for them to try to build a usable site. They'll never get a product manager or do a focus group. Even reading a book is perhaps too much to ask. As long as they can say in a news blurb "we're doing eGovernment," no one will notice that its ill conceived and poorly designed. You'll notice that they can't even use the utah.gov domain name since that's too closely aligned with the executive branch.
05:17 PM | Recommend This | Print This
A Simple Tool for Better eGovernment
Dave Fletcher reports that Ferret, a publication of the Utah State Library, is now available as a weblog. Ferret publishes links and editorial about web sites that may be of interest to Utah State agencies. They're too modest. These web sites are probably of interest to anyone with an interest in government. Two things of note:
- As Dave points out, now that its a blog, it will probably be more current.
- More importantly, now that its a blog, there's an RSS feed. (check on the right hand column for the link).
I've subscribed to the RSS and look forward to having it show up on my desktop regularly. I'm not sure why its not hosted on a utah.gov domain.
04:59 PM | Recommend This | Print This
Language Doesn't Matter: Its All About Design
Grady Booch has been around the programming language scene for a long time (I read some of his papers in grad school). He's now Chief Scientist at Rational Software. Grady was interviewed in February issue of .NET Magazine. There's a number of little gems in the article, but one jumped out at me because I've been contemplating it a lot lately. On page 2, Grady says:
I used to be a language bigot; I thought ADA was the way the world was intended to program. But we're talking a couple of decades ago. It predated even VB I think. Alan Cooper had done his thing around that time. And at the time I really thought that the choice of language was one of the most important decisions you could make on the development team. But then I encountered this wonderful language called Smalltalk, and C with classes which because C++, and then all the scripting languages and eventually Java. As I go around the world working with lots of projects, the choice of language is important because it brings to the table lots of specific skills, lots of specific tools, lots of specific patterns and idioms for use. And there certain things I can do better in some languages than others.A little later he says:
In the presence of Web services the choice of languages becomes even less important. Because you're going to use little snippets of scripts and lots of different languages on the Web user interface side, such as VB, maybe Java, lots of things. Again, it's raising the level of abstraction. Languages now help us glue those little pieces together and therefore fit in the interstitial spaces of our systems.
This is a fact. I've been playing with a lot of tools for building and serving up Web services and they all make use of a variety of languages to get even simple tasks done. The programmer is forced to map designs not into one concrete syntax, but several---all at once. At times, this cacophony of languages stands in the way of rational thought about the problem. To make matters worse, many of them are not even particularly well designed. As I've said before, most XML-based languages are syntactic arsenic. And if that weren't bad enough, a lot of the programming required to make Web services work isn't even programming with a language, its managing multiple configuration files.
The problem with all of this is fairly straightforward to understand: the nature of programming is building correct dynamic system behavior using static texts (i.e. programs). To do this, programmers have to build mental models of how execution will happen and envision that execution as they program. Mostly, they do this implicitly and, for most, its hard enough to do in one, well thought out language, let alone 5 or 6 bad ones. One last quote from Grady underlines this:
...we're working in a domain where applications are intrinsically concurrent and distributed, and must be secure. That is not a simple domain in and of itself. Not to be disrespectful of the average code warrior, but building distributed concurrent secure apps isn't a core competency of such people. They may make some good local decisions for those three issues; however, building a Web-based system that is extensible, scalable, and secure requires good global policies as well.
In such an environment, the role of the architect becomes even more important. Architects are supposed to be looking out for these global policies and designing the system so that the average code-warrior can make good local decisions producing a global end result that is functional and performs well. Even so, I think we could do a better job of creating languages to help manage these abstractions. Seems that no one even tries anymore. Just slap an XML syntax on a simple workflow semantics and claim you're cutting edge because you've sprinkled angle bracket pixie dust on your incomplete scripting language.