Google Analytics

Wednesday, January 18

Great customer service is about consistency

Couple of years ago at Pothi.com, we were working on a Hindi poetry book. It was a collection of poetry of the father that the son was publishing.  It was a very big deal for the son. He had organized a family gathering and book launch in his home town. We were working on a tight schedule but the books were shipped with time remaining on the clock. The book launch was on Tuesday and the consignment reached the client on Saturday afternoon. Shortly afterwards, I received a call from them.

Getting a call or an email from the clients after they have received the books is not uncommon. There is something about holding your own printed book in your hands that moves people. It is usually a time to celebrate after the long time spent working on the book. However sometimes, things go wrong.

When our clients opened the consignment, shiny new books came out. However on leafing through the pages, they realized that while the cover was of their book, the interior was something entirely different! At 16:00 PM on Saturday, I came to know of this. Family members were coming from all over India for the launch. Our client was to catch his flight in 2 hours. Something needed to be done quickly if we wanted to avoid the disaster.

The courier services usually pick up their last consignment at 21:00 PM. This left us with 5 hours to reprint the books, bind them, trim them and handover to the courier. With some exceptional work from our production people, we somehow managed to put the consignment in before courier cutoff time. To put it in perspective, it usually takes 3-5 days to produce and ship the same order under normal conditions.

However, due to time crunch, we were not able to laminate the covers on this set. Also we were not sure if the direct shipment to the small city would reach in time. So we printed another set of 100 books next day with proper lamination and shipped them to Delhi on Monday to one of the relatives who was driving down to the home town on Tuesday for the book launch. By God's grace, all the copies reached the client in time and they had a memorable book launch.

I sometimes relate this story to friends and they all look reasonably impressed with how we dealt with the situation. Someone suggested that this is an example of great customer service and we should mention it more prominently. However I do not agree.

As humans when we are faced with a crisis situation, we are often able to pull off things that we wouldn't be able to do normally. This is true for both physical as well as mental abilities. Given that we, as entrepreneurs, keep hearing that having a satisfied customer is very important, we often go out of our way to achieve that in a crisis situation. A well known startup in Bangalore offered a client an air ticket in lieu of a bus ticket when the bus didn't show up!

But this has nothing to do with customer service. This is crisis management. The customer service is the part that makes sure that such crisis do not happen in the first place. It means that as a company, you are consistent (hopefully consistently good) in your service delivery and in your communication with customers. The best example of Pothi.com's customer service would be the author who never had to call me up to resolve any issues. Good customer service is a boring story that is repeated with every customer every day with no drama thrown in.

Why is it important to keep this distinction in mind? Because it is easy to confuse your crisis management with your customer service. Let us say you have a standing offer of a full refund in case a defective product is delivered to your client and you actively fulfill it whenever the need arises. Given the situation of most companies in India, you will be doing something quite rare and your customers will be happy. The more the need arises, the more chances you get to make a customer happy and you feel good. Unfortunately, more such cases mean that your primary service delivery is not working up to the mark. While as a customer, I would be happy that you made up to me in a crisis situation, I will quickly move to someone else if they are more consistent in their service delivery.

The other difference is that the promised delivery levels should be set keeping in mind the sustainability. What you can deliver is a crisis situation may not be sustainable on an ongoing basis. If you require maximum 3 days for delivering something, promise 3 days even if you can deliver in 2 80% of the time.

So in summary, while the grand stories of crisis management make for interesting story telling, a good customer service needs to be exactly the opposite - predictable, consistent and sustainable. In other words, a boring story.

Saturday, January 7

For every risk, there exists some reward! Not!

Some people seem to misunderstand the "high risk, high gain" maxim. They argue that if I am taking some risk, I should get the reward. I recently heard a candidate expecting 100% raise when considering an opening at a startup.

When you hear "high risk, high gain", pay attention to the order. Risk comes before gain. Often much before. And the fact that the (monetary) gain is not guaranteed is part of the risk (in the startup environment).

While you are at it, find out about the concept of expected value. Your aim should be to maximize the expected value of your reward over next N years of your career. Now depending on your definition of reward, that might mean that you are better off in a job with a bigger company which is perfectly rad. But at least, you won't have ridiculous expectations!

PS: Just as I was posting the article, the right idiom occurred to me: You cannot have your cake and eat it too. So there.

Thursday, August 11

Technical Goals for 2011: Mid Year Review

Although we are already 2 months past the middle of the year, I decided to do a "mid year" review of my technical goals for this year to see how am I doing. Here we go:
  • HAML, SAAS & Coffeescript: No progress :(
  • SproutCore & BackBone.js: After a cursory look, I decided to explore Backbone.js for our upcoming project at Pothi.com. Still getting a feel of it.
  • Learn Haskell: Deferred
  • Git: Since Drupal moved to Git, it is hard to ignore it and I am beginning to get familiar with it. But given that we use trac, I don't think we will be leaving SVN anytime soon.
  • Android: No progress
  • SQL: Finally starting to dig into this. Not a very planned effort but in 6 months managed to understand few more nut and bolts of Mysql. Ran a few Explains finally :). Learnt to generate slow queries log and also managed to fix some obnoxious queries sitting in Ubercart.
  • Beautiful Code: I realized that "finishing" beautiful code is not the right way to approach it. I read it one chapter at a time whenever I feel like and also re-read the earlier chapters to better understand what are they saying. Meanwhile instead of "Founders At Work", I have acquired "Hackers & Painters" and will be reading that.
This doesn't look impressive at all. But there are 2 new set of tools that were not in my initial plans that I have come to know and use. One are Job Queues/ Message Queues. Used Celery for building a system for crunching the Streaming API of Twitter. Planning to also check out BeanStalkd and other Job Queues.

The other set is deployment & configuration management Tools like Cap, Fabric, Puppet and Chef. Puppet and Chef were not immediately useful for the task at hand but Fabric and Cap were. I decided to stick with Fabric since it is more generic in nature and it is Python. I am consciously trying to not get into one more language. Want to spend some time to get better with Python.

A related discovery was Vagrant which is a tool for provisioning Virtual Machines using Oracle VirtualBox. Using a combo of VirtualBox and Fabric, I am setting up a "few clicks" server for building and deploying for Pothi.com. Will also use it for all other projects once the basic code base is more stable.

The surprising thing is that looking back at my initial list, I now feel that it was all over the place with no core theme tying everything together. If I somehow manage to get to all of them by the year end, I would have gained familiarity with some good tools but I doubt I would be any good in using them. The tools need to be something that I can get down to do real work with. Also they should be something that improve my work. The things I ended up playing with fit that pattern. They fix some basic loopholes in my tool chain. So keeping that in mind, here is the new list:
  • CoffeeScript & Sass
  • BackBone.js
  • Celery/ MessageQueue
  • Fabric/Vagrant
On a related note, I submitted a talk proposal to Pycon India, 2011 and it has been accepted. The talk is about various ways of implementing Naive Bayes Classifier in Python and comparing their performance and pros & cons. So I will probably be in Pune for 2-3 days in September. This is going to be my first technical talk since grad school. Need to finish the work I want to cover in the talk and then start working on the presentation.

And while I have been busy with this stuff, Jaya has been killing it with Python. She has been super productive since she started using Python couple of months back and has already automated a significant part of our backend operations, thus opening up a lot of bandwidth. If there was any more proof I needed that Python is the one general purpose language everyone should pick up, I now have it! :)

Tuesday, May 10

The saga of plain text password

Recently, one of the major Indian payment gateways, CCAvenue was reported to have been hacked. Medianama has good coverage of it including an interview with the very bureaucratic sounding CEO of the company.

While a payment gateway getting hacked is a big news, the bigger revelation were the clear text passwords that came out of the compromised database. There have been a lot of comments and discussions about this all over the startup blogs. Reading through those comments it appeared to me that there is a lot of confusion regarding passwords and how to securely store and transmit them. Saurabh Nanda has a good little primer about things to read. This is my attempt to clarify some of the things involved.

First a few basics. Any situation that involves passwords has 2 parties. The aim is to establish identity between parties. For simplicity, we will assume that it is the user that wants to establish his identity with the service. Login/Password system works on the basis of a shared secret. You tell the service the correct shared secret and it identifies you. One important thing to remember here is that the secret is being established between the user and the service only and not between the user and the employees of the company providing the service. For example, we would not want a database admin in Google to be able to read all our mails.

On to the specific questions.

Is it ever OK to store password in plain text?

There are 2 scenarios of an application dealing with passwords. One is of a web app like Gmail that allows people to sign up and hence must keep track of login passwords. The other is of intermediate apps like browsers that store users credentials for various services to make it more convenient for users. The answer for the first kind of applications is "never". The answer for the second kind of applications is "if done properly".

Basically, the applications in second category need access to the original password when logging in the user to service provider. So they cannot hash the password and store that. They can certainly encrypt it but that may or may not be any more secure then a plain text password stored properly. Even here, adoption of OAuth is reducing the need to deal with user passwords directly.

What is the difference between Encryption and Hashing?

Encrypted things can be decrypted if the key is available. So it only pushes back the question of security one layer deep. How do you ensure the security of the key? You can encrypt that also but then you need to safeguard the key-key. You get the drift.

Hashing is a one way road. A good hashing function has 2 properties: hash value of 2 different inputs is different. And given the hash value, it is extremely difficult (computationally) to retrieve the input string. Because of the first property, we can safely store the hash value in place of the original password. Whenever we need to match, we can just compute the hash and match it to the stored value. Because of the second property, even if someone gets access to the hash values, they cannot recover the password easily.

Are all hashing functions created equal?

No. In the past decade, the commonly used hash functions like MD5 and SHA-1 have been successfully attacked. So the current recommendation is to use SHA-256, SHA-512. However the suggested best choice for password hashing is bcrypt. The advantage of bcrypt is that you can tune it to be as slow as required. How does that help? Well, it increases the resources required to mount a brute force attack significantly. Normal hash functions are built to be very fast. As a result, attacker can compute hashes of millions of passwords per second. With bcrypt, that number goes down several notches and makes the approach unfeasible.

Why is is OK to receive a one time password in plain text?

Since the service should never store the original password in plain text, if the user forgets the password, the only way out is for him to choose a new password. To allow that the service needs a way to establish his identity. This can be done with the help of security questions. A more popular way is to send a mail to the registered email address of the user.

Now if the reset password email contains your original password in plain text, that is a huge red flag. This means that the site stored your original password. Remember that it is not possible to recover original password from the hash.

But it is ok if the mail contains a one time password in plain text. This password is not meant to be stored and used more than once. So even if someone gets access to it, there is no issue. If on the other hand, if someone intercepts your mail and gets access to it before you do, even a hashed/encrypted password will not make much of a difference. The way to prevent the snooping is to use https for your mail and other sensitive connections.

Perhaps this is nothing new for most people but given that even Reddit guys were found storing plain text passwords, it is always good to double check on your security practices.

Monday, March 28

आर्तनाद


हार कर उठने की क्षमता अब नहीं मुझ में रही,
वो ह्रदय की मधुर ममता अब नहीं मुझमे रही.
अब तो मैं संसार के वारों से होकर छिन्न-भिन्न,
बन गया हूँ रूद्र हिंसक आर्तनादी नरपशु.
अब मेरी सब इन्द्रियां रक्षा में मेरी व्यस्त हैं.

मधुर गुंजन मधुप का गांडीव की टंकार है
दामिनी का दमकना अब युद्ध की ललकार है,
दीख पड़ते हैं मुझे चहुँ ओर अपने शत्रु दल,
सांस की आवाज़ मानो शून्य में चित्कार है.
मान था अभिमन्यु सा, अब द्रोण सुत सी वेदना!

Thursday, March 17

The Saga of Static IP

Recently we decided to get a static IP for our office broadband connection. We are a long time Airtel customer and usually not very annoyed with their service. They are quick to respond to complaints and things mostly work as they should.

We placed a request for a static IP and were told that it would require a 1 hour downtime to set up. 1 hour is no big deal and so we asked them to go ahead. Our connection went out at around 5pm on Thursday evening. Someone was coming to set up the router for static IP.

The person arrived at 9pm and started configuring the router confidently. We were hoping it to be a fairly quick and smooth process but suddenly the disaster struck! The 4-5 steps which he had been taught didn't get the link up. After that it was one hour of him calling various people, trying out some really weird configurations and generally hitting refresh. After struggling with it for 1 hour, he told us that our router did not "support" the static IP. He promised to come back next day morning with another router. However he would not be able to come before 11-12pm. So much for a 1 hour downtime!

Next day morning, we were running the office on our mobile 3G connections and a Reliance Net Connect stick and waiting for him to turn up. When I called him up at 11, he said that he had a meeting in the morning and won't be able to come. He was sending someone else. This other person came around lunch time, managed to get the Internet running but the router he brought was not a wireless router. We had a wireless router earlier and half of our machines run on wireless. We didn't have enough cables to connect all the machines. He again promised to come back with a wireless router soon. I had a hunch that I am making a mistake believing him but had no option. Our office had wires all around now with half of the machines off the network.

When we called him next day, pet came the reply that the wireless router is out of stock. They had no idea when it would be back in stock and when could they give us one. Remember that we have actually paid extra to Airtel to get a wireless router. We lodged another complaint with the customer service. They promised to resolve it by the evening but it was clear from their tone that they really don't consider this a serious problem. As a result of the complaint we again got couple of calls from local guys and they repeated the excuse that the wireless router is not in stock. Now I would have readily believed them if there was even an iota of sincerity in their voice. But it seemed like I was needlessly harassing them for wireless when I should have been thankful that at least my Internet was working!

After realizing that we were not going to get anything useful by breaking our heads with them, we decided to give the wireless router which supposedly didn't "support" static IP, a chance. With some googling and common sense, we had our static IP and wireless running in half an hour! So much pain and frustration for something which should not have been a problem in the first place if only Airtel would have taken time to train their field staff well.

Consider the situation. Airtel probably uses a handful of router models - 5 or may be 10. The 2-3 most basic things to do with a router are setting it up for dynamic address, for static address and setting up the wireless. How difficult is it to equip all their field staff with printed instruction sheets for these basic 3 tasks for these 5-10 models? When taking the request for the static IP, they had asked us the model number of router, so they already had that information. The only thing that the guy needed to do in our case was to delete the old config on the router and create a new one from scratch instead of trying to modify the old one. How difficult is it to mention this one fact in the instruction sheet for our model number? It would have saved them multiple phone calls to support center, multiple field trips and an annoyed customer.

But instead of investing in things like this, they recently invested 100s of crores in changing the logo and brand identity. Somehow they fail to understand that a shiny logo and funky tune cannot make up for such bad service experiences. I can only shake my head in disbelief and frustration!

Saturday, March 12

From Low Priced Editions to Fair Priced Editions

A major group of Indian publishers is up in arms against a proposed amendment to the copyright act of India. Put simply, the said amendment allows for the export of any edition of a title into India even if specific Indian editions are already available. 

There are some genuine points both for and against the issue. However the debate has long since devolved into fear mongering and finger pointing. One of the interesting claim of the publishers is that the said amendment will also legalize the export of Low Prized Editions of text books and technical books back to USA and UK. As a result, publishers in those market are likely to stop giving licenses for LPEs.

I personally think that it is very far fetched. There is enough protection against such imports in USA/UK markets. Some short sighted foreign publishers might pull out but then that should not be the guiding factor of our policies anyway. However the reaction from publishers set me thinking in another direction.

Given its status as the outsourcing hub, a very young population and growing number of people comfortable with reading in English, India is a big market for Technical Books and Text Books. Why is it then that Indian publishers are happy to be the printers of LPEs rather then develop their own titles in this market? It is estimated that 70% of Indian book market is of Text Books. This includes everything from Primary to Higher Education. Most of the text book publishers of India seem to be focused on school segment. The titles that do come out in the Higher Education Segment are not up to the mark - bad quality of writing & bad production value. And I am yet to come across a solid technical book (IT and CS are the areas I can vouch for) by Indian authors, published by an Indian publisher. Most of the known names O'Reilly/Shroff, Pearson, Prentice Hall basically bring out LPEs of titles originally written and produced outside.

With the growing number of good techies in India, there should be no dearth of possible authors in India for technical subjects. Recently one of the startup founders wrote a book on SaaS. There is also an increasing number of open source contributors in India. However, due to the fast changing nature of technology, the technical publishing is also a very quick moving market. To survive it today requires adoption of technology, quick adaptability to market and out of the box thinking. The competition is intense, especially from the increasingly high quality free content available online. Indian authors will typically need more hand-holding as compared to their foreign counterparts. But the size of the opportunity seems to be large enough to be worth the risk.

We can either let someone else do all the hard work and be happy publishing LPEs or we can go out and carve out a piece for ourselves. Then we can throw away this tag of LPE and have our own Fair Priced Editions. Given the amount of changes happening in the publishing industry currently, I believe that there is a window of opportunity here. I just hope that there are people in Indian publishing industry who see the possible threat to LPEs as an opportunity!