Tag: commentary

Orbitz.com Considered Harmful

(Offtopic warning: my site is mostly about technical matters, not about consumer affairs.)

Well, that wasn’t fun.

We had reserved, or so I thought, a hotel stay of a few days, using Orbitz.com.  Life intervened, and it became necessary to cancel.  We attempt to cancel.  It turns out that we hadn’t reserved a hotel stay. We had paid in advance for a hotel stay, which was 100% non-refundable. Don’t stay, still pay the whole amount anyway. (With considerable effort, including intervention by the management of the hotel in question (at which we’ve stayed a number of times before), we were finally able to get it resolved.)

While in a free world one should be able to sell such a toxic product, it generally does not make sense to buy one, certainly not as the default. One lesson to learn: read the terms carefully, there are dragons in there.

But I think that is the wrong lesson. The right lesson is much simpler: do not do business with a vendor (Orbitz) who offers such foolishness. Rather, use them (or any similar size) to find a hotel / flight / whatever, then leave their site and go make the purchase by other means, some means by which the more traditional (and sane) terms-of-sale are used.

The Right Way to do Monitoring and Mass Administration

Over the weekend I flipped through these slides about Nanite (code), and it got me thinking about system monitoring (again), as well as mass administration tools (Puppet and its younger competitor Chef). The key bit from the talk is the idea of using a proven, off the shelf messaging server (RabbitMQ) as the communication bus among a set of processes running on many servers.

I would like very much to see a piece of software that puts these pieces together:

  1. Monitoring features, like those in Zabbix or other similar tools
  2. Mass administration features, like those in Puppet
  3. Run it over a messaging bus rather than a homegrown communication mechanism

Such a system would allow some very nice improvements:

  • The messaging bus could provide real time “presence” information.
  • Urgent events could be sent immediately, rather than polled.
  • Urgent administration changes could be sent over the same communication channel as normal operations, unlike (for example) the puppetrun mechanism is puppet.
  • The specification for how a server is configured could be integrated in to the specification for how it should be monitored. This would be an enormous improvement over the current state of the art (in open source tools anywhere) where these two concerns are separated in to tools that don’t talk to each other.

In addition to the feature improvements, I suspect that both kinds of tools (monitoring and administration) would find they can get by with a smaller codebase by outsourcing the communication bus to a messaging server.

Saying No to say Yes

In The Secrets of Consulting (a book, along with its sequel, about a lot more than consulting), Jerry Weinberg offered the Law of Raspberry Jam:

the wider you spread it, the thinner it gets

I thought about that a lot a few years ago when I attended the AYE conference (an experience I heartily recommend), along with the “Yes/No Medallion” that Jerry borrowed from Virginia Satir. Years onward, I am still struck by the  notion of saying No to say Yes. My inclination and habit is to say Yes to many projects, many features, many business ideas, many of everything. This has obvious benefits but also has a cost – sometimes I am spread too thin to have the impact I intend.

The fewer things I (we, you) focus on, the greater our impact on those top priorities. Of course there is inevitable pushback from associates, customers, and family members about Nos. This pushback is worth facing, because the more Nos, the more powerful the Yesses.

(An aside: in a half hour of online research, I was unable to definitively conclude where the name of the above Law originated.) 

Incompetence -> Progress

From http://www.theodoregray.com/BrainRot/index.html

“The most profound engine of civilization is the inability of a larger and larger fraction of the population to do the basic things needed to survive.  Many people fail to realize this.”

“Technology’s greatest contribution is to permit people to be incompetent at a larger and larger range of things.  Only by embracing such incompetence is the human race able to progress.”

It’s a good read, with important thoughts on civilization and education.  It is part of the introduction to a book about Mathematica, a truly amazing piece of software. (Mathematica, was amazing when I used it in the 1990s, I can scarcely imagine what it does now.)

Need text? Hire a Writer

To help create the document I mentioned earlier about the merits of custom software development, I hired a subcontract writer. The only typing I did was a bit at the start and perhaps a half-hour of editing at the end; all the rest of my input was in the form of spoken-word audio recordings, which I find fast and easy to create.

A critical factor in making this worthwhile is the categorical difference between a writer and a transcriber; I’ve used transcription services with excellent results, but a transcribed talk is far different in form and polish, than purposefully written text. The process was roughly like so:

  • I posted an ad on Craiglist to find a technical writer
  • I wrote short notes/outline of the topic
  • I recorded an audio ramble of my ideas for the content
  • Writer sent me draft #1, organizing my ramble in to a coherent form
  • I recorded audio feedback
  • Writer sent me draft #2
  • I recorded audio feedback
  • Writer sent me draft #3
  • I made a bunch of edits, and posted it

This worked out well, in several ways. The first, minor payoff is that it took a bit less time than just writing it myself. In retrospect it was only a minor time savings; if I had just sat down and wrote it all myself in one go, I could have finished in a handful of hours.

The second payoff was much larger: although I could have theoretically done it all myself, most likely I would not have done so yet. My personal threshold to get started and keep the process moving was much lower. Engaging assistance transformed an idea for what could happen, in to a process that did happen.

The third payoff is that this process is another useful tool in my toolbox; there is a big difference between know that I could use such a tool, and having actually done so.

Thus, I consider the experiment a success, and will almost certainly use the same process on more projects.