Why I hate Zendesk

In Jenkins project, I use JIRA. And for CloudBees customers, we use Zendesk. And I positively and passionately hate Zendesk. It’s quite painful for my usage, and even more disappointing as many of the things that make me suffer can be fixed so easily. So I decided to write this to make myself feel better.

The way we use Zendesk, it’s really not that diffrent from the way Jenkins JIRA is used, which probably applies to just about any software projects. People report strange behaviours in software, stack traces, log files, etc. We look at those, sometimes ask for more information, ask them to try a new binary, get a new data, and repeat this process until it runs its course. I don’t think we are that unique.

This kind of support work is a lot like a detective work. You look at various log files and stack traces, you connect dots, and you derive a certain hypothesis. Sometimes additional facts are discovered later, or a hypothesis is proven wrong, and you start digging in another direction.

When I’m doing this, it’s very important that I “cite” my sources correctly. I’d like to be able to say “the stack trace in comment #7 indicates that X is doing Y when Z. This is consistent with ticket #150 comment #9.” But I can’t do this in Zendesk, because they do not have any sequence number nor ID for comments. So the best I can say is “comment made by John 11:59 on Apr 13th 2013 in ticket #150″, and if somebody (like me 6 months from now) wants to see the referenced comment, he has to manually find that comment. This is like writing a research paper without a bibliography section, or how a sloppy program managers refer to tickets (“what happened to that ticket — you know, the stability issue from Acme Corp a few weeks ago?”). This is particularly maddening because obviously they have an unique ID in their database, and I can even see it in the HTML source. It’s really only a minor additional work to make comments referencible. And yes, JIRA has permalinks for comments for long time.

There’s a lot of useful features to be built in this direction — for example, I’d love to see log files visible online, in such a way that each line is separately addressible as URL, and allow agents to left comments, much like how you review code. In this way, I can leave the audit trail for my detective work so that others can retrace that later.

Another thing that bugs me is the inability to edit comments that have already been posted. Zendesk supports markdown, which is good; it helps you organize information a lot more than just plain text. But some customers don’t know that, and file a ticket in plain text. Similarly, when the ticket comes from the e-mail gateway, often line wrapping and etc messes up the format.

In JIRA I often edit the ticket description to fix this up — convert a section of the text to a fixed-width font, remove line wraps, delete the pointless e-mail footers, etc. Have you ever had someone who posted 1500 lines of log records as a comment? Move that off to an attachment, and edit that out! In other situations, I want to go back to my earlier comment and strike out something, for example when my earlier hypothesis turns out to be wrong. But I can’t do that either in Zendesk. (And Zendesk doesn’t let you collapse a comment, either.)

I can go on forever, but I should be working, not whining, so I’ll finish this up with just one more problem; inability to edit a closed ticket.

Since CloudBees uses Zendesk for supporting paid customers, developers are expected to bring tickets to completion, to the “closed” state. I’m pretty sure we aren’t unique. The problem is that once a ticket is closed, one cannot make any further updates.

Say another ticket was filed later by somebody else that is seemingly related? Can’t add a comment to link to it. If a detective work led to an old “unresolved” case and you came up with a new hypothesis that might explain a behaviour? Can’t put it there. Adding a new tag? Nope.

My colleague Ben Walding made an observation that Zendesk probably has a different kind of audience in mind — ones where a relatively unsophisticated “level 1″ support people sitting in an office somewhere in Asia goes through 100s of tickets every hour as fast as possible. In other words, Comcast or AT&T kind of support. Prominence given to features like a templated response backs up this assumption. I can only assume Zendesk works well for those use cases.

But if you are considering Zendesk and your use case is more like ours, the sophisticated software support, then I hope you learn from our mistake and stay away from Zendesk.

LEGO Earth project

I play LEGO a lot with my daughter, and I’ve been obsessed with making spheres. My last sphere building attempt was building a mini LEGO Earth in 2009. While I enjoyed the project, it was also clear to me that there is a room for improvements.

The main issue is that the the “pixel resolution” of LEGO is rather low that many of the distinctice coast line shapes are just not visible. I also later discovered off-by-one bug in the program that I used to compute the color assignment to tiles, which skewed the projection around seams.

So around March last year, I decided to build a bigger version of it, at the whopping 3x scale of the earlier project. This will surely give me enough resolution!

The construction starts with building a 36x36x36 stud cube from LEGO technic beams. The studs are facing all 6 directions.

The lumps at corners are for changing the stud direction as well as for supporting the structure.

The idea is to basically build six peels and put them on the surface of this cube, completely covering the cube:

Each peel is big enough that it needs its own support structure. When attached to the cube, the center of each peel will not be connected to anything, so it needs to be fairly sturdy. It would be fun to write another program that does the structural analysis and figure out how much support would be adequate. Perhaps a TODO for the next version. The clipboard you see on the left is the instruction computed by my program

The support structure is mostly made of 2×4 bricks. Just for this purpose, I bought several 1000s of them:

On this support structure, I then built up the arch over it. One section is almost complete!:

One thing I wasn’t too careful about in the planning phase was the seasonal change of the Earth surface.

The image I based the texture mapping on didn’t have any sea ice, so I use a different source to add in sea ice. Unfortunately, those two sources did not agree on the season. If you look carefully, the sea ice is the winter level, but the land ice is the summer level:

On the positive side, the higher resolution really paid off. Here are two Earths side by side, showing the same side.

We are used to seeing the Earth as a two dimensional map projection, so our mental image of the Earth is quite skewed. Building an actual sphere was quite an enlightening experience, as I get to really look at the actual proportions of things. For example, I used to think that when I fly from the US to Europe, I’m going about one third of the Earth, but it turns out it’s more like just one fourth. Africa is really, really large, and the mouth of Amazon river is so vast that the brown area caused by the river-carried dirt stretches a hundred kilometers. For that I gave is a distinctive brown tile:

This version of Earth is about one meter across. It’s quite heavy, but I can still carry it by myself.

Once I assembled it, I still had some more fun by calculating various numbers based on this scale.

For example, the highest point of the Earth, Mount Everest in Himalayas, is only about 0.3mm tall above the sea level. That is, it’s not even one tenth of a LEGO plate high. In fact, he whole Earth crust is only about 30km deep, so that’s only a half LEGO plate high. If I wanted to correctly model the interior of the LEGO Earth, then I have to basically build a red sphere all the way, except the top-most plates. It’s almost like we are living on the egg shell, and no wonder the continents moves over time!

In the same scale, the Sun would be about 50m (200ft) in diameter at 6km / 4miles away. That’s big enough to comfortably fits the Statue of Liberty inside. Someone please build that in LEGO and we will put that and my Earth together at the accurate distance!

Finally, if you put this Earth in my home at San Jose, the furthest man-made object, Voyager 1, is past San Diego and into Mexico, flying at the speed of 1.5m/h. Picture a garden snail that crawls past the LEGO earth, slow that down 100 times, and that’s about the speed of Voyager 1. No wonder it took 35 years to get there — go Voyager!

Anyway, that’s it. Now that I’m finished with this project, what am I going to build next?