Off we go to London

The alarm rang at the ungodly hour of 5.00 a.m. at 10.30 we had a meeting in London. One of the fun things about working for a small startup like Bluetail is that the programmers have to make sales calls and get to meet the customers. When I used to work for Ericsson things were complete different, in 14 years I never ever met a real customer, the people who actually pay money to buy our products.

The amazingly cool thing about this is the flood of ideas that come from the visits. Bluetail's business idea is to do stuff for ISPs - that way we get to meet a lot of ISPs. The fun thing about this is that despite the fact that all ISPs offer different combinations of services (POP3 and IMAP4 accounts, web hotels, DNS, and a basic TCP/IP dialup connection for surfing and FTP etc.) none of them solve their problems in the same way. There are as many different architectures as there are ISPs. I've seen mail systems based on Sendmail, qmail, qpopper and Microsofts Exchange Server using, BSD, Solaris, Windows-NT and running on anything from PCs Sun workstations, Sun enterprise servers, Compaq multi processors and home made hardware.

Out of all this apparent mess certain similarities emerge. Common problems - different ad hock solutions. This is where cool things begin to happen. In the first release of the Bluetail Mail thingy we made certain guesses about what would and would not be important to our customers. I guess we almost subconsciously tended to think that the things we found most difficult to implement would be the things our customers appreciated most. After all, if it's bloody difficult to implement then it must be amazingly useful for our customers. This turned out not to be the case. The most difficult thing to implement in the Mail robustifier is "hot session failover" - without going into details this is the part of the system that saves a user transaction if a server crashes in the middle of a user session, transferring the session to a new server. The basic idea is that if a server crashes in the middle of a user session then the user won't notice anything. This is actually pretty tricky for POP3 and SMTP and very difficult for IMAP4 - In fact the product does this for POP3 and SMTP and doing this for IMAP4 will be dependent on customer demand, we can do it, but it needs a fair pile of code.

And now for the amazing bit - session failure is not what the customers want most of all. In fact if asked to prioritize my feeling is that it would come pretty low down on the list. What they do like, and wax lyrical about is the "overload protection" and "session logging" - and this was much easier to implement than session failover. What's more fun is the inspirational effect that meeting half a dozen ISPs has. At the Bluetail HQ we tend to discuss problems in closed groups and after a while we get to the point where we think we completely understand a problem. Meeting customers provides an essential reality check - here we find out if our ideas really work "in the field". Talking to customers provides new inputs and new frames of references which kicks us out of our old ways of thinking and often leads to ideas for much improved products.

Back to the front line

While the hardware and software setups of the different ISPs we have visited are very different the human factors involved are very similar. Every time we go to meet a new customer the same thing happens. A typical Bluetail team consists of one sales person (Jane or Ann-Louise and two teckies) - Jane and Ann-Louise are there to make sure we do actually try to sell something and the teckies are there to talk to the teckies from the ISP. To save space I'll call Jane and Ann-Louise M (short for Marketing) and the teckies T.

The pattern is always the same. M does a few slides, who we are what we do. Pause. We do the teckie bit. Then comes the attack. M has never really understood this.

What about gratuitous ARP?
Can you have two IP addresses on the same interface?
What's the maximum number of sockets can have open at the same time?
How do measure CPU load?

During these sessions the Ts get highly excited and the Ms get worried. While on the surface it appears that the Ts are being nasty to each other what's really going on has deeper significance. This is where the Ts establish Bluetail's technical credibility (or lack of it) - this is were the ISPs teckies get to answer the question "Who are these guys from Bluetail - are they for real and "do they know what they are talking about?". This process can take up to a couple of hours. After this the process calms down and the Ms go into action. "Where do we take it from here?" - "Next meeting?", names, contacts. The business cycle begins.

In the taxi after the meeting comes the postmortum:

    "Those guys were really nasty" says M - "Like being savaged by a couple of Pit Bull Terriers"

    "No they weren't," I protest, "They weren't nasty they were just asking a few questions"

    "I'll never understand you guys," says M - "you spend all your time in the meeting shouting at each other and then come out smiling - Teckies ..."

The fun thing about is to be in at meeting number one. Who knows what will happen? What stared at our 10.30 meeting may turn into a year of collaboration between two industries and to our mutual advantage, or may squizzel out like a damp squid. Who knows? - that's why I get up at 5.00 am to find out.