Enterprise = Answering the wrong question

"Enterprise will follow legacy to become a common insult among software creators and users"

I don't think legacy is a bad thing (definitely better than failed projects), but I definitely agree with David H.H.'s post that the concept of "Enterprise" software has lost a lot of luster. I have been part of a couple of these roll outs, and it's never pretty. There's something about software that is supposed to everything that makes it do nothing particularly well. This "Coding Horror" post linked to in the comments is even more to the point. Enterprise buyers seem to purchase based on the number of checkmarks in the feature list, rather than based on how well any of those check marked features actually work. Would you buy a new car based purely on the spec sheet?

I can think of one situation where we had a large number of users on a client/server ArcView system that I had put together in 1996-1999. We worked out a nice locking system for multi-user access at different sites and built a lot of custom extensions. There was a massive push in 2001 to replace it with a web based "Enterprise" system based on ArcIMS. I tried to help them out for about six months, but it was obvious that ArcIMS at the time was only going to be able to provide about 50% of the features and performance to which the users had been accustomed. Plus, they now had to ask someone to add new base map data instead of being able to add it themsleves among other indignities. I escaped prior to the first deployment, which was a complete disaster and the project eventually skidded to a halt.

Honestly, there was no need to replace the system, it just needed a new name for political reasons as two projects were being merged. As it stands, they are still cruising along as we head into 2006. The project might actually make a little more sense now that we have some better web browsers available, but there are some tasks that you just don't want to do in a browser. I feel like the enterprise version of Photoshop would be browser based, with some workflow where you had to get managerial approval before you changed your color pallette.

What languages should students learn?

In an article that is creating a fair amount of discussion, Joel (on Software) Spolsky rants against kids learning Java in school. I think it's a bit of a strawman, as I don't know of any schools that only teach Java to CS majors, but that would be pretty sad. I think in four years you ought to have time to really learn a couple of languages, and get exposed to a few more. I wish I had been able to take MIT's 6.001 [see image for objectives].

I like the approach of starting on both sides, with a high level and a low level language. If you can see how assembler works, you can start to see the reasoning behind things in c works, and then when you see a bunch of c code, you understand why a lot of the memory management and abstractions were added to the other languages. I like the idea of understanding what things are more efficiently accomplished in a high level language versus which things need to be done in a low level language in a hands on fashion.

Now, what about the people that can only deal with the abstractions? I mean for reasons of patience or just lack of interest, some people aren't interested in understading things all the way down. I don't think it's wrong to stop at a particular level of abstraction for those people. Maybe they don't need to know about pointers, but it is going to limit what kind of work they can do effectively.

Maybe the right answer is that you have to understand at least one level of abstraction below where you work. I think that is enough to uncover one level of problem. I have run into Java programmers that know a little c++, but didn't realize all of their variables were pointers to memory, and they do have problems writing code that takes advantage of that fact. The pointers are still in there in the languages that abstract them away- it's just a little harder to screw them up, or make them do exactly what you want.

Excel as interchange format

I really like the concept Dion Almaer outlines here. If your users already have a flexible data entry tool that they are experts at using, why not allow them to use that as the data entry tool for your system? To me this is real re-use, and despite Dion's claim that it isn't sexy, I find it rather attractive.

To me this is the essence of what is wrong with letting the Enterprise Architects dictate user experience. James McGovern, an enterprise architect whose book I really like, has been going on and on about how "web 2.0" is not something that architects should be thinking about. [see his 2006 predictions post for an example] I really think it is something that they should be focusing on- improving the user experience. I think if you think that way, you build an Excel import function. If you think the bad way, you build a complex user application that is buzzword compliant ESB, SOA, EBI, etc. forgetting that the spreadsheet is the application whose usability and flexibility drove the adoption of the PC (and that your corporate developers probably aren't as good as the people at Microsoft that wrote Excel).

Bird's Eye Article Popularity

Over on All Points Blog, they consider why a NY Times article on Google Earth was the most emailed on the site for a couple of days,

I think the reason is very simple- people have been unaware of the existence of high quality commercial satellite imagery and aerial photography. The only thing Google can be accused of is lowering the price, making it easier to use, and publicizing it to the point where uninformed people in positions of power can begin to make themselves look foolish in the press. The headline on the article, "Governments Tremble at Google's Bird's-Eye View" is an alarmist overstatement (given that there was no evidence of trembling presented) that colors the perception of the reader, making something out of very little.

It reminds me of the situations that occured when various governmental organizations began putting public records online. A lot of people were uncomfortable with what was considered public record (how much they paid for their house, how much money they gave to political candidates, etc.) and the fact that you could click to it from the comfort of your home instead of waiting in line at some county office somehow made it newsworthy.

Google Homepage Widgets

Google has provided a little interface- compare to JSR-168, for adding sections to their homepage. I read the document and added a little one to run the mobile version of Backpack in about 3 minutes. Obviously, there's a lot more you can do with this- particularly the location aspect.

<?xml version="1.0" encoding="UTF-8"?>
<Module>
<ModulePrefs title="Backpack" />
<Content type="url" href="http://username.backpackit.com/mob"></Content>
</Module>

no more DOCTYPE...

Drop the: "Back when we cooked up XML in 1996-97, there were good reasons to have that ugly upper-case gibberish at the top of your XML documents. That was almost ten years ago; now it’s time to do away with it, and also time to have a spec for Doctype-free XML."


Tim Bray is ready to drop the doctype. I am too. I am not overly fond of discussing the foibles of my colleagues, present or former, preferring to discuss topics in the abstract. However, a particularly heinous form of idiocy that I was exposed to in a previous consulting engagement was related to this. These folks were operating on a network that was not connected to the internet. They were concerned that all of these doctype declarations in XML were referring to things like http://www.w3.org/TR/html4/strict.dtd. So, they wanted to do the logical thing and create websites on their internal network that resolved to those addresses and host the DTDs there. You know, so they could download the DTDs and parse the files. I think a similar group at that organization expressed a great interest in starting a project to provide a buzzword-compliant web service to actually perform validations of XML against Schemas and DTDs. Which would of course have been accompanied by an enterprise policy that forbade anyone else from validating XML....

I really think anyone writing a parsing application needs to make sure that they don't put in any dependencies on actually reading the DTD. I always try to parse XML using XPath in a relatively fault tolerant way. I honestly think that one of the reasons for the ascendancy of Internet Explorer was that they went out of their way to try to display as much as they could of any old hacked up HTML that is out there. This to me is the best part of Tim's post->
"...it’s usually a bad idea for a document to express an opinion as to what its own schema is. Most useful languages have more than one schema, and it’s the absolute right of someone receiving a document to decide whether it meets their definition of “valid” before they use it, so they’re going to make their own decisions as to which schema (if any) is appropriate."

I reserve that right.

Google Earth book

Okay, so there is a book coming on Google Earth and Maps, Hacking Maps and Earth, which is a 500 pager from Wiley in the cheesy looking ExtremeTech series.

Picked this up from Squidoo somehow...

Servlets and Earth

More of a tracking link for me than anything else, but here is a decent article in Java World on writing servlets to interact with Google Earth, bi-directionally.

Ruby updates

Even though I should probably be coding, or doing the books, or something else useful, Andrew Glover's basically hype-free Ruby off the Rails (an good intro for Java developers) is up on IBM's developerWorks.

There's also a new Manning book, Ruby for Rails coming out in April that focuses on learning Ruby as you build with Rails.

Finally, this isn't anything new, but the Ruby Scripts for SketchUp page is full of cool stuff, but I am still waiting for them to release some things related to their Google Earth integration. You can find some references in their forums. If you have seen those really cool 3D models of buildings that people have been throwing together, you may not realize that building models is pretty easy compared to other 3D tools.

I think if the decision had been made this year, ESRI might have chosen Ruby over Python for ArcGIS scripting. As it is, I am glad they have kept a simple language in there, even if it isn't Avenue...

Rails 1.0: Party like it's one oh oh!

Rails 1.0: Party like it's one oh oh!: "15 months after the first public release, Rails has arrived at the big 1.0."

Getting to a 1.0 release is really going to make this easier to use in a variety of contexts. Ruby and Rails have really brought a sea change in my way of thinking about the best way to develop software. I am not 100% happy with it, as it seems to be a little too "database driven", but there are a lot tricks in there to make it less so. I think that is one thing that really separates it from things like Oracle's HTML DB. HTML DB is great for generating database driven web applications, until you want to do something outside of the framework, then you are alone in a cold dark place with nothing but burning pl/sql code to keep you warm.

There's something nice about having code generation vs. a pure wizardry approach that leaves you nothing to modify. The downside is, of course, that your changes are overwritten if you re-gen. A beauty of Rails is that if you add a field to the database, it is accessible in the model, but it still must be added to the user interface. One mode of development is to start by modifying the templates for code generation such that one can always add fields and regenerate the UIs, at least. I haven't gotten that deep into Rails yet, but that's the direction I am going.

One of the things about Rails that really surprised me was that the scaffolding generates a web service to go along with the web pages for a particular domain object. I think this is a really interesting feature that will also probably be assimilated by database companies, if it already hasn't been.