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.