Xaprb

In case you live under a rock, the MySQL conference starts on Tuesday. There are 8 concurrent tracks of content. Aside from my own talks, here are the sessions I would most like to see.

On Tuesday:

• Tutorial: Innodb and XtraDB Architecture and Performance Optimization. Peter’s talks are always great, and this is a perennial favorite. If you have never been, you should go to this one. You will realize how little you really know about InnoDB/XtraDB, and how much it matters.
• Tutorial: Linux and H/W optimizations for MySQL. Last year I tweeted that Yoshinori’s tutorial was the 3rd edition of High Performance MySQL, and I really wasn’t exaggerating that much.
• BoF session: Percona XtraDB Cluster. I believe that this is one of the few truly groundbreaking changes to MySQL — right up there with “MySQL has transactions now” and “MySQL adds replication.”

On Wednesday:

• MySQL Plugins – why should I bother? Sergei is the co-author of a book on plugins. Their power is not to be underestimated.
• Getting InnoDB Compression Ready for Facebook Scale. Compression is very powerful — if we can just get the implementation to work better. Facebook, apparently, has done that.
• The 5 minute DBA: MySQL DBA 101 for Non DBA’s. Get started fast with Matt Yonkovit’s friendly, engaging and relevant talk. Spoiler: it’s longer than five minutes.
• MySQL Optimizer Standoff MySQL 5.6 and MariaDB 5.3. Peter at it again, this time digging into the advances in newer releases of the server, which make a huge difference on some common and important workloads.
• Scaling MySQL Databases for the Web. This is the “Vitess” talk, a technology I’m extremely keen to hear about. It’s now powering YouTube’s backend.
• BoF session: Tungsten User Fest. Tungsten has matured into a very interesting technology in the last couple of years.

On Thursday:

• Oracle to MySQL migration. Marco Tusa has actually implemented some of the most impressive migrations in MySQL’s history.
• Spil Games: Outgrowing an internet startup. This should be a great talk about running MySQL in a busy startup in the real world.
• Here I’m torn between MySQL and SSD: usage and tuning and Common Schema: a framework for MySQL server administration. (I’m always torn between at least 2 or 3 talks, but in this case especially so for some reason.)
• Verifying MySQL Replication Safely With pt-table-checksum 2.0. If you aren’t verifying that your replicas have the same data as their masters, you need to, and this is the tool to do it.

Clojure In Action, by Amit Rathore. Manning, 2012. About 400 pages.

This is a lucid and interesting introduction to Clojure and the LISP family of programming languages. It’s been years since I programmed in LISP and I found myself recalling those days, at the same time as I learned a lot more than I used to know. Indeed, I realized that my knowledge of LISP was only superficial, and that I probably ought to take some time at some point and learn it deeply enough to have the epiphany people talk about. (Can I plead that I’ve had the epiphany with SQL? No? How about XSLT — it’s basically LISP in XML? Drat.)

The book is in two parts. First you learn about the fundamentals of Clojure, how it works on the JVM, state and concurrency, and so forth. In the second part there’s a lot of deeper and more specific topics. You could say that the first part is about learning the language and environment, and the second part is about how to really put Clojure, um, into action. Conventions, idioms, and the like make their appearance in both parts, but in the second part there’s a lot of specific topics like building web applications with Clojure and creating DSLs.

I haven’t read the whole book. I saved parts of it for later. Perhaps that’s a shame, but perhaps I’m just not ready for them yet, either. In any case I found the parts that I read to be well worth my time.

I’ve been a consultant for over five years now and I’m just beginning to learn some basic things. One of them is how to spot a lose-lose customer relationship. I say I’m just beginning because I continue to find new lose-lose scenarios that I don’t see coming.

If things are set up such that nobody can succeed, it’s best to walk away from the deal. With 1400+ customers now, you might think we haven’t walked away from many deals, but that’s not true. We are very careful to choose our customers. They don’t just choose us, we have to say yes in return. I used to be the sole sales person and even in the hungry early days I politely declined or referred a lot of people elsewhere.

Some interesting rules got written on the wiki, such as never do business with someone who confesses to being drunk. This applies also to people who’ve been up all weekend desperately changing things at random, drinking Red Bull, and can’t even remember what the original problem was or stop their minds spinning long enough to describe it clearly. I cut my losses and backed out of one such case, after essentially solving it and not billing for it, because I could see that I’d already lost, and was going to lose more and more badly the longer I stayed engaged. That person still posts online occasionally about what terrible service he got. Public criticism is another no-win situation: you can never take troll bait and come out ahead. (I’ve let myself be goaded into responding a couple of times. It’s hard not to do.)

Another of my rules is that anyone who insults one of your consultants is trouble. I remember someone who thought Vadim’s Ukrainian accent was another nationality I won’t mention, and demanded to talk to a senior person, not realizing who Vadim was at all. It would have been funny if it wasn’t so bigoted.

I remember a disputed invoice from someone who claimed that he couldn’t understand the consultant, who was European (and had successfully completed the work). The customer had a strong rural Southern accent, so I dropped back into just a little bit of my own native Southern accent to imitate him, and said “I know, it can be hard to understand a [nationality] accent.” The man immediately warmed up to me and confessed that “I’d, you know, I’d hoped someone from America would do the work, because, you know, well, I support our troops, you know what I mean?” Racism is racism, y’all.

Then there is the customer who hires you because he (or she) can’t deliver the results he’s supposed to for his business, but has insisted internally that his approach is the only right one. He’s painted himself into a corner, with no way to save face, and now he’s looking to make you the scapegoat. If you give him the advice he actually needs, he’ll vilify you for not solving the problem he asked you to solve, because you’re making him look bad. If you figure out that this is happening, and agree with him, the project will fail and he’ll blame you then too. All he wants to do is get you to demonstrate that it’s not his fault he can’t satisfy his boss’s impossible demands.

Still another scenario is when you end up working with people who didn’t hire you and who don’t buy into your consulting at all. They may resent the boss bringing in the outside help because it implies that they’re incompetent, for example. Or you may have the support of the technical staff, but not buy-in from the upper management. I remember one instance when the administrative staff simply kept changing the access credentials. By the time we got access again, all of the systems we’d been working on were gone and replaced by new systems, and the landscape was completely different, but nobody would tell us what the new situation was because they were too busy doing their “real” jobs, which didn’t include babysitting the consultants.

There are probably dozens of other war stories about situations that are set up to fail from the start. Some of them, in hindsight, could have been managed differently and ended up as customer love stories. But a consultant who can handle an extraordinarily difficult technical problem combined with a delicate interpersonal situation is a rare one indeed, and it’s hard to predict whether even the most skillful consultant can rescue a difficult situation.

For example, it’s sometimes possible, with great interpersonal skills, to win the trust of the technical staff in situations such as the “revolving door VPN access” customer. If you get a toe in the door, you may be able to demonstrate that you are helping their careers without taking any credit for it yourself, for example. The book The Trusted Advisor talks a lot about this type of personal relationship building. But this is a touch-and-go situation at best, and only the most talented and observant consultants in the best of circumstances are likely to succeed.

In the end, consulting is a personal relationship. Businesses don’t have relationships; people do. And you have to choose your business relationship partners carefully, just as you choose your friends and romantic partner. Developing the ability to spot a person or situation that’s stacking the deck against you can be a valuable asset. It’s much better never to enter a poisoned relationship than to have to leave one.