OK, so I haven’t blogged much lately. Now that we’ve got the new mainframe in production maybe I’ll be able to find more time for it.

I’ve been reading a book I got when they closed down the 13th floor library, The Trouble with Computers by Thomas K. Landauer. It looks pretty good, except it was written in the early 1990’s before most people had heard of the web, so I’m not sure what he might say differently if he were writing today. Anyway, I wanted to quote this:

It is not only the initial design of computer software that is thus so often flawed. The way in which software is produced and deployed makes it almost inevitable that it will miss its mark in providing the right functions for its users. After the initial specification of a product, which may involve executives and managers of the people who will use it, some of whom may have done the job at some time in their past, software is usually developed by a group of programmers with no further contact with customers until the system is complete. The programmers add and subtract features and functions reflecting their own fantasies of what the job is like and under the assumption that the users are people just like them, which is never true. Systems are only rarely tried out on users in their environment before they are sold.

I think this is one of the things we’ve been able to do right in the past. *DACCT (the predecessor of *DEFINE) came about when John Wheat went and sat in departmental accountants’ offices and watched what they were doing. Having programmers working in the departments they support helps too. This is not to say we couldn’t do even better in the future.

With the holidays well over, it’s probably time to blog some again.

I was reading this article about Red Hat at The Register, which linked and quoted from this Forbes article about Salesforce.com, and I’d like to highlight this part:

The theory of enterprise software is that it is cheaper to buy an off-the-shelf solution and configure it to your needs instead of building exactly what you need from scratch. Some companies are great at using off-the-shelf products and others waste a lot of money. But for most companies, the trade-off works. It is cheaper to buy and configure than to build.

What is less widely known is that the range of processes covered by standard software is modest. In his book, Business Process Management: The SAP Roadmap, SAP Co-CEO Jim Hagemann Snabe says, based on research, that standard software covers about 20 percent of the processes in any given business.

I had the sense that moving to PeopleSoft or an equivalent would still leave a need for a lot of local, custom development, but having it meet 20% of the need is much smaller than what I would have guessed.

I’m not the only one who thinks XML could be made simpler: XML 2.0 proposal by Elliotte Rusty Harold. At least some of these ideas are good: predefining all the HTML 4.0 entities would be great; getting rid of internal DTD subsets and CDATA sections and leaving validation out of the core spec are winners; building in proper namespace support should have happened already. I’m less sure about others: XSD simple types are way too complicated, but I never felt the need for XML types to match the type system of whatever programming language I happened to be using.

As long as I’m talking about XML, Adam suggested in the comments to my previous post that vendors add complexity to solve the problems of their customers. I responded with another comment, but I’d like to expand on that. I do think that the problems of big enterprise customers are less complicated than most people think. The real problem is that enterprise vendors usually sell to people (executives) who don’t actually use their products, and therefore often base their decisions on check lists of features, so that the vendor claiming the most features wins. YAGNI (“you ain’t gonna need it”) is a losing proposition in this environment, so architects design for every possible contingency, which means things get more and more complicated.

A couple of interesting links via Cameron Moll:

Periodic Table of the (html5) Elements It’s fascinating how similar to the original chemical version this turned out.

Spacelog Original NASA transcripts of early missions, in an easy-to-read and easy-to-link format. (Each individual speech has its own URL.) So far they have Apollo 13 and Mercury 6.

Chris Bowles asked me what I thought about the new design for the University’s home page, and I decided to post my thoughts here.

If you want to get technical, it does a pretty good job on the XKCD test—the only thing I couldn’t find relatively easily was the University police phone number. But it clearly follows the letter rather than the spirit of that cartoon: the big, eye-catching stuff is still about “branding” rather than helping the visitor find what they’re looking for. I’m not saying branding isn’t important, but I’m sure for the vast majority of the people coming to the web site it just gets in their way.

Also, I thought I’d mention that the layout is a bit broken when I view the page in Safari (the browser I use most.) I think this is because I’ve set the preferences to “never use font sizes smaller than 12.” Why do page designers love small fonts so much?

James Clark: XML vs the Web.

You should read the whole thing, but here’s his conclusion:

So what’s the way forward? I think the Web community has spoken, and it’s clear that what it wants is HTML5, JavaScript and JSON. XML isn’t going away but I see it being less and less a Web technology; it won’t be something that you send over the wire on the public Web, but just one of many technologies that are used on the server to manage and generate what you do send over the wire.

My take on XML is that Microsoft and IBM and Software AG and all the other big software vendors took a technology that was originally a simplification of something that had grown over complicated (SGML) and saddled it with layer upon layer of complexity, because then they could sell tools to manage that complexity. In the meantime, people that needed to get stuff done and didn’t have huge budgets for tools moved on to less complicated technologies.

[update] I should probably add that XML is still very useful and won’t go away any time soon, and I don’t regret the effort I’ve put into learning XML technologies. But there’s a lot of junk built on XML—SOAP, UDDI, WS-*, etc.—that could (and should) die unmourned.

Since the 1980’s IBM mainframes have come with a built-in hypervisor that allows you to partition the machine into multiple systems. (As I recall, Amdahl had this feature first.) For over a decade, we’ve run three partitions on the administrative computing system: one partition where we install new versions of the operating system when we receive them from IBM, and make sure it’s working as delivered; a second where we make our local modifications and install third-party applications to test them out; and finally, the production partition that everyone except the systems staff uses. This means that all developer and quality assurance testing occurs in the production partition.

I’ve mentioned this to a few people, but now I’d like to publicly float the idea of breaking up the production partition and spinning out the test and quality assurance environments into their own partitions. The primary advantage of doing so would be a decreased possibility of testing efforts inadvertently affecting production data. (This would particularly apply in batch, where currently developers have to come up with different names for test data sets.) A second advantage would be an enhanced ability to make sure non-production work doesn’t receive an excessive share of the mainframe’s capacity.

The main disadvantage would be slightly more complicated procedures for migrating code and data between environments. Also, setting this up would require some effort, and developers would have to change some of their habits.

So what do y’all think?

I did the early voting thing last week, but today’s the actual election day. And here’s a story about a future election: An Election, by John Scalzi. Here’s a snippet:

“And what do we know about the demographics of the third district?” James asked.

“It’s a human-minority district,” David said. “I know—”

James held up his hand. “How long has it been since a human councilperson held the third district seat?”

“It’s been a few election cycles,” David admitted.

“A few?” James asked.

David threw up his hands. “Fine. It’s been forty-four years,” he said.

As a bit of follow-up to my post the other day about “customer service”, Tim Bray has a post about what you call the people you’re writing software for: No More Users.

I just wrote a little piece about how to write software, and it contained a few references to the humans who carry the mobile devices on which the software runs, and who interact with it. I found myself referring to these individuals as “users” or “the user”. Gack; I hate that word.

In fact, I hate it almost as much as the word “content” which, in the Internet-biz context means “Words and pictures and sounds that you create and I monetize.” Anyone who uses the acronym UGC in my presence should prepare for a nasty reaction.

In the comments, the most popular suggestion is “customers”, but you know how I feel about that. (Although it may be a little better for these people, who may actually be selling their software to their customers.) Anyway, most of the people who use things I write are software developers, so I like to call them … wait for it … “developers”. As for the people they’re writing for, how about calling them “students” or “faculty” or “staff”?

We found out a couple of days ago that there’s a proposal to change policy so that only people working in Operations have card-swipe access to the data centers; the rest of us who work on the machines there will (under the proposed policy) have to be checked in and out by the operators.

Well, this seems like a great idea. Now every time we need to go into the data center we’ll get to stand around and wait for an operator, who will have to interrupt whatever he’s doing to let us in. And what benefit does this provide? It certainly isn’t going to make things any more secure. (The amount of effort being expended on physical security for the data centers already seems way out of proportion to the risks.) It will, however, increase the feeling that management doesn’t trust us or respect our abilities. (And hurt morale, as was so eloquently expressed in yesterday’s ITS all staff meeting.)

Some people seem to have the idea that if you set up sufficient rules you can prevent bad things from happening. This never actually works: as long as you’re doing something, there’s a chance that things will go wrong. The best way to get things done with minimal risk is to trust people but hold them accountable for the results.