Are Bookmarking Sites/Apps Worthless?

Bookmarks
Photo by Arria Belli.

I've been a fan of Springpad and used it - mostly - to save bookmarks and some notes. I've now switched to Evernote, as the former is quite buggy, especially the web interface (which is the main one). Funnily enough, their Android app is very good. On the other hand, Evernote's web app is simply non-existent.

Anyway, I've been saving hundreds of bookmarks over the last year or so. You know, the "I'm going to need this later" line of thought that forces you to save just about anything.

The problem is that I've never searched my bookmarks. Not even once. That's because when I'm looking for something, I don't remember whether I've bookmarked something related to it. After all, we save things so we don't have to remember them, right? It's a vicious circle that makes me just assume I don't have any bookmark, and I end up using Google. This is kind of transparent. It's my subconscious that makes the decision to ditch my bookmark collection, it's not a rational mind action.

My conscious conclusion is that my subconscious is totally right.

After all, Google has several advantages over bookmarking apps. The first is speed. No app known to man is faster than Google. Another one is relevancy to what you're looking for right now, which is different from what I was looking for a week ago. Last but not least, Google has invaluable up-to-date results, because I might have bookmarked something good, but chances are that it's outdated or simply there's something better out there.

So, taking notes is useful, saving plain, stand-alone bookmarks is a waste of time.

Customer Support Tips for mISVs

I want to share a few things I've learned about customer support in a small shop like ours.

1. Don't Fear Customers
The first thing I've observed is that customers who contact support are the ones most likely to stay with you over time. They're in for the long haul, otherwise they'd not even bother asking you questions or reporting bugs. Even if they're reporting terrible bugs, treat them well, provide answers, and they'll stay. Take the chance to show that they've made the right decision when they chose you over other solutions available on the market.

2. Be Personal
Never, ever act like a heartless company and show that you're human. Avoid using ticket-based support systems, use email instead. When you think about it, a ticket makes you feel like you're just a number inside a larger system. One of the many. Instead, email is personal. You want personal, one-to-one communications. If you're wondering how you can manage many support requests via email without dedicated software, the answer is simple: GMail or Google Apps. It might seem foolish, but you can leverage the fact that the same account, e.g. support@acme.com, can be used by multiple users in multiple locations at the same time. Using labels/folders to distribute workload is very easy, and you get a ticket-less support system that makes customers feel like respected, almost-unique human beings. Priceless (and free).

3. Fix Small Bugs Immediately
It's likely that you'll receive many reports of small, trivial bugs. It's easy to shove them into your issue tracker as low priority, as they're not dangerous and don't cause data losses. This often causes that they'll stay there for a long time, if not forever. Instead of queuing them below higher-priority issues, fix them right away and deploy the fix immediately, then inform the customer that the problem has been fixed. This kind of near-real-time bug fixing is very appreciated by customers.

4. Explain Why Something Bad Has Happened
When customers report something terrible happened, and it's your fault, take all responsibility and explain why it happened. This not only helps you preserving your credibility, but also gives the customer the feeling that you have everything under control and you can fix the problem. "I don't know" is fine in lots of scenarios, but not in this one. If you can't explain why something bad has happened, then investigate and provide a reason as soon as possible. You don't have to go into much detail, just provide an explanation that you'd be comfortable with if you were the customer (and see #5 and #9).

5. Be Honest
This should be obvious: never, ever lie. Lies tend to be discovered, and when that happens you lose a customer (or many). Even in the worst case, be honest and tell the truth. Jason Fried would say "Own your bad news".

6. Always Say Thanks
I always answer first-contact emails with "Thank you for your interest in ..." and to first support queries from existing users with "Thank you for taking the time to contact us". Show that you appreciate the fact that the customer took the effort to write you an email. It's something that takes time and should be respected, especially nowadays.

7. Don't Expect Thanks
In most cases, customers will not say thanks to you. Expect this, but don't take it personally. It's just fine (but remember to say thanks when you contact customer support of some product/service you use).

8. Avoid Temptations
You'll have disgruntled customers who'll send you 20-line emails with no punctuation and lots of rage. It's very tempting to answer them with the same kind of content, but avoid that. Instead, wait a couple of hours and then write a calm, respectful and clear answer. This usually works well and turns a disgruntled customer into a happy one, often because they don't really expect a decent answer (or an answer at all).

9. If I Were in Your Shoes...
Before hitting Send, always re-read your email imagining to be the customer. Would you be happy with such a response?

10. When in Doubt, Ask
When you really can't figure out what the customer is saying, simply ask for clarifications. Just make sure that it's clear what is not clear (no pun intended). It's always better to delay the resolution a bit rather than providing a wrong or incomplete answer.

Automate to Innovate

At Threeplicate we recently automated a ton of things that we used to do manually until a few weeks ago. They're all related to software development, but after all that's what we do.

We always had the mandatory continuous integration builds for all our projects, managed by the excellent Team City, and we've always been able to make a build in one step, but we wanted to go even further.

For ScrewTurn Wiki, every time we push changes to our internal repository (hosted at Codebase), the build server generates 3 ZIP packages (source, binary for local storage, binary for SQL Server storage) and publishes them to our website as development snapshots. It also updates the project's public repository mirror on BitBucket. This level of automation allows us to release fixes to the public with exactly zero effort and with a latency of less than 5 minutes. We still don't have automation for production releases, as they involve updating the website, but it's something we'll work on sooner or later.

For Amanuens, not only we can make a build in one step, but we can also push a new version to production to Windows Azure with a single mouse click, with zero downtime and full service continuity. This level of automation allows us to release new versions very frequently, even multiple times a day. That is why we're able to fix small and trivial bugs in only a few hours. In this case a production deployment takes roughly 40 minutes and has a cost of about €0.15, and that is the reason why we do not launch new deployments automatically on new commits (we'd have dozens deployments a day).

For the Amanuens website, with the help of Deploy, we publish updates automatically in a matter of a few seconds after a commit.

Now, automating things not only gives us geek satisfaction, but has at least two undeniable advantages:
  1. it saves a lot of time that can be spent doing useful things, because babysitting a new Azure deployment takes time and attention
  2. it reduces human mistakes, because it's extremely easy to forget something along a boring and convoluted process.
All in all, automation fires innovation, because the time you save allows you to focus on real work. That's the philosophy behind Amanuens, by the way.

Software Developers: Are We Dooming Our Own Future?

The migration from PCs to alternative computing devices has already started in the consumer market. With the gradual increase in availability of web applications that allow you to do pretty much anything you want, it's appropriate to imagine a world without powerful PCs on every desk (or lap). Instead, it's very likely we'll see a consumer market populated by diverse devices with just one thing in common: a powerful, standards-compliant web browser, and a bunch of native apps for things that really can't be done otherwise.

That's easy to predict. Everyone is saying that nowadays.

Personally, the only relevant desktop applications that I use are:
  • Microsoft Office
  • development tools (Visual Studio & Co.).
It's only a matter of time before web-based office apps will be real, viable replacements for their desktop counterparts. Actually, I believe that most users (including myself, perhaps) would be perfectly fine with Google Docs. It's just a matter of changing one's habits (and having ubiquitous connectivity).

Over time, we'll switch from a world dominated by PCs capable of running just about anything, to a world of web-enabled devices. The only problem is that there will always be a part of the users that will need powerful computers. Developers, designers, architects, engineers, and so on. With PCs sales shrinking, PCs will get more and more expensive, and that will be a problem because if now with €2,000 you can get a monster PC, that will no longer be true in some years from now.

While I can imagine Visual Studio completely built in HTML, CSS and JavaScript, it's very unlikely we'll ever see something like Adobe After Effects as a web application. I'm not using After Effects as a random example, but as a real-world example of an application that is widely used for semi-professional video editing and post-production. Now think for a moment how many professional-looking videos you see every day, not only on the TV, but on the web. Producing video is now easier and cheaper than ever before because powerful hardware has become a commodity.

The same applies for many other areas, including software development itself. We're now able to build grand applications that run on inexpensive devices simply because so far we've built behemoth applications that required monster PCs to run at decent speed. PCs are now inexpensive because, so far, our users have been purchasing new hardware like crazy. That is partly because Intel's marketing is very good, but most importantly because, on average, software runs faster on faster PCs.

I'm making a wild prediction, but once that trend inverts and hardware prices will begin rising, making grand applications will be increasingly more difficult and expensive. It's something that will probably happen in 10 years or so, but what will happen then?

Shipping Your Website

There is an interesting guest post by Patrick McKenzie on the Fog Creek blog about web marketing. Patrick is some kind of SEO and web marketing legend, so the post is highly recommended to all IT entrepreneurs. Besides the practical advice he wrote, one thing really struck me. Patrick summarized it in one single mind-blowing sentence:

"The website is a shipping software product of the company."

It's incredibly obvious... once someone tells you.

Every day we take measures to better monitor how Amanuens works, detect errors and performance problems. Recently we even completely automated production deployments (way cool BTW: with just a mouse click, a new version of Amanuens gets deployed in production). Yet, our website is some kind of second-class citizen. It's updated every once in a while and we review its performance randomly, when we feel like it.

Considering the website a real product, a real piece of work that is key to the company is an important shift in mental processes and I believe it's key for bringing it from mere existence to full life.