Monthly Archives: August 2009

Using Mac OS X

Tim Bray has a post today titled How I Use OS X. Here are some of my responses.

Dock Control · It’s on the side because vertical space is at a premium on a laptop. I prefer the right side but can’t think of a good reason.

Almost everything in the Dock is a running application. Most of them I start once and run forever. No shortcuts, no URLs, no folders.

Mine’s on the left side. I think I put it there because it’s kind of like the menu bar, and top and left are the “beginning” sides in our writing system. I have the dock set to small size icons with maximum magnification because there’s a lot in there. I also have it set to hidden by default. I keep several folders I want to be able to access quickly in the dock.

The Dashboard · I don’t use it. Silly thing.

Amen.

Exposé · I have mouse-to-bottom-right set to show the desktop, otherwise I don’t use it. This may be eccentric.

I’ve never found Exposé to be very useful, although one Snow Leopard review I read today said it’s a lot better in Snow Leopard.

Spaces · Don’t use it. Maybe I should try again; in the early days there were just too many important programs (Lightroom, NetBeans) that didn’t play nice with it.

I’ve found Spaces extremely useful. (I’ve never used Lightroom or NetBeans, though.) I keep Firefox and Vienna in space 1 (my “web space”), Mail and iCal in space 2 (my “personal management space”), Terminal and Aquamacs Emacs in space 3 (my “open systems development space”), and tn3270 in space 4 (my “mainframe development space”). Other things go in whichever space they happen to be in at launch.

Bible5

I saw this on Cafe con Leche, and I had to pass it on, although if you haven’t been following the development of HTML5 you probably won’t get any of the jokes: WHATWG to start work on “Bible5”.

After their successful work on HTML5, CSS5, XML5, SVG5, and Web5, the
WHATWG has announced that it has started work on a new version of the
Bible, to be called “Bible5”.

“Initially, one of the most obvious changes will be a change to the ten
commandments”, said Ian Hickson, the group’s leader and idealog. “For
instance we shall be changing ‘Thou shalt not kill’ to ‘Thou SHOULD not
kill’ with the necessary reference to RFC 2119. Clearly after a couple of
millenia experience with this spec, people have not been doing what the
spec requires, and so we are merely updating it, modernizing it you might
say, to reflect actual usage. I mean, what use is it having admonitions if
most people are not going to follow them?” he asked, adding “That was a
rhetorical question. I mean, what use is a spec that forbids things? It
just makes it harder for people to be compliant.” “That was also
rhetorical” he hastened to add.

Follow-up on my open letter (Updated)

Last Thursday I and several coworkers met with Brad to discuss the open letter I posted here a few weeks ago. Here are a few thoughts:

Update: rereading this a few hours later, I don’t think I’ve expressed myself as well as I might. Here goes again.

I believe Brad and I are in substantial agreement on these points:

  1. ITS in general, and administrative computing in particular, have suffered from a lack of leadership and vision. Providing leadership and a strategic vision are top priorities.
  2. We need a concrete plan for how we might migrate our applications that are currently hosted on z/OS to some open systems platform, so we can correctly evaluate whether or not that would be a good idea. (I emphasize that having a plan and deciding to implement it are two different things.)
  3. The current “mainframe efficiencies” push is not a solution, it’s merely a delaying tactic to give us some time.

There are some areas where I think we disagree. I want to stress that I’m perfectly comfortable with disagreements, as long as people don’t misunderstand my positions. If everyone always agreed with me, I’d think something was very wrong.

  1. I think the concrete plan for how we might migrate off z/OS should wait until we have a better idea of what our strategic vision will be. I believe Brad thinks we can’t wait.
  2. I think that we’re relying too much on external consultants to develop the plan. Now, let’s not forget our biases here: Brad has spent most of his professional life as a consultant, while I have spent most of mine as an internal employee. So this disagreement isn’t really surprising.

As for my letter, when I started writing it I didn’t think it would make any difference, I just wanted to get my perspective out in public. By the time I was able to publish it, a lot had changed, and in some ways it felt a lot less urgent, but I went ahead and followed my original plan. I do feel like my position is clear now, so I’m satisfied.

End update (original post follows.)

We all agree that ITS in general and administrative computing in particular have suffered from a lack of leadership and vision over the past few years, and I understand that fixing that is one of Brad’s highest priorities. That will take quite a bit of time, however, so what do we do in the mean time? Brad feels that going ahead with an open systems migration analysis is important, where I would prefer to wait.

Along those lines, I’d like to point to a post I saw a few weeks ago: Managing IT in desperate times. Here’s one of the points:

If anything that costs non staff dollars or invokes risk looks avoidable, avoid it. This is not the year to move to DB2, experiment with network virtualization, merge some SQL-Server DBs, implement system wide identity management, or do anything else that’s risky and expertise intensive. Have your people do what they do, focus on helping them keep their jobs, talk long and loudly about improving performance and reliability, but don’t undertake anything that’s new and avoidable.

Here’s what makes me nervous about a migration off the mainframe: It’s a big IT project, and most big IT projects fail. I’d like to think that we’re smart enough to make it succeed, but it will take a lot of resources. If our budget is really constrained, will we have the resources that we need to pull it off? Will there be sufficient reserve resources when we run into unforeseen problems along the way? This kind of project is more likely to work out when we have extra resources, not when we’re scraping along with just enough to get by.

Another thing that bothers me is the reliance we’re placing on consulting firms. I hesitate to quote Randy Ebeling because there seems to be a feeling that everything’s changed since he was here so what he said no longer applies, but I think this captures something that is constant: when asked if he thought he was smarter that high-priced consultants, he responded, “I don’t think I’m smarter than them, but I do think I care more about the University of Texas than they do.” The incentives for consultants who may come and go are different than those for long-time employees, and maybe as a long-time employee I’m biased but I think those incentives point me toward things that will serve the University best over a longer term.

Here’s another bit of advice from the article I linked above:

If you absolutely can’t avoid doing something, maximize your own staff involvement, incur hardware costs in preference to outside expertise costs, and be prepared to abandon previously ironclad corporate standards if that’s what it takes to bring in cheaper and more functional stuff like Linux, open source applications, and Solaris.

(Note that the author is not a mainframe bigot; he’s actually a Unix bigot.) I think the advice to maximize staff involvement and prefer hardware costs to outside expertise is sound at any time, and particularly in difficult times.

Anyway, at the end of the day it’s not my decision to make. My original motivation in writing the letter was to make sure my opinion was heard, and I think it has been. If it changes anything, then great, if not, well, I am quite aware that I may be totally wrong. Whatever we do I’ll work to make it succeed as best I can.