> I also like people who get things done.
If you’ve been working on your startup for
two years and have nothing to show, that’s
a pretty bad sign. I’ve discovered that
most people are really good at finding
obstacles.

"Obstacles"? Okay:

I tried to install the Express (free but
limited in the amount of data it would
handle) version of Microsoft's SQL Server.
After all the clicking for the install,
which seemed to go well, the program would
not run. Nor would it repair, uninstall,
or reinstall. I had to reinstall the
operating system on that bootable drive
partition. Eventually I got SQL Server to
install and run, wrote code for it, put
data into it, etc.

> Just get started and deliver now. ...
An extreme example of this is, I wrote the
first version of Gmail in a day!

Write code quickly?

Okay, I've done some of that: Back on
OS/2, the e-mail program put one icon on
my desktop for each e-mail message sent or
received. It was also very slow for doing
anything. Bummer.

But I'd long since learned and used Rexx
(the elegant IBM scripting language by
IBM's Mike Cowlishaw in England) and C and
had used both for TCP/IP.

So, I got and read the basic IETF
(Internet Engineering Task Force) RFC
(Request for Comments) documents for
e-mail and right away wrote my own Rexx
code to receive e-mail. Less than a day.
The next day I got a copy of a simple
version of Sendmail and for sending e-mail
had some Rexx code running in a few hours.

For the sending, I also implemented, again
with Rexx, a simple feature for
nicknames for individual people and also
for groups of people.

I liked it.

Since it was all command line driven,
sending to a long mailing list was easy.

Soon I found that I really should be able
to handle base 64 en/decoding so wrote
some C code for that. Less than a day.

Worked fine for years.

The user interface was my then and still
favorite text editor, KEdit, a PC version
of IBM's XEdit.

But recently my motherboard got sick, and
I have parts on the way for a nice, new
computer. In the meanwhile, on my
computer, dozens of times a day a Web
browser at a site with a lot of JavaScript
fails and a few times a day the operating
system reboots. A few times a week I have
to run the Windows CHKDSK on my boot
partition. And the computer is so sick
that Outlook won't install. Very sick
computer: Problem seems to be on the
motherboard between main memory and the
processor.

So, I got my old Rexx-C based e-mail going
again for sending. My computer is so sick
I can't run the C compiler for my old C
base 64 code so found some clever, nicely
fast Rexx code for that and am using it.
But now also need to decode
"quoted-printable" so I wrote some code
for that in Rexx in about an hour -- works
great!

I don't have a copy of Sendmail, so for
sending have started to use Gmail.

Sorry, Paul, I don't like Gmail! At this
point, I'm so close to having my new
computer up and running, I'm reluctant to
write my own code from the simpler RFCs
for sending e-mail so will stay with Gmail
for sending.

I've written other code quickly:

(A) FedEx was about to die due to the BoD
afraid of the challenges of being able to
schedule the fleet when the growth got up
to the plans. I was consulting and
teaching computing and computer science at
Georgetown University so got a
time-sharing terminal to IBM's VM/CMS,
and, in addition to the teaching, learned
CMS and its editor and scripting language,
designed and wrote some PL/I (which I was
already good at), joined FedEx, all in
eight weeks. Soon VP Roger Frock and I
ran the code, pleased the founder F. Smith
and the BoD, and saved the company.

(B) While in grad school, on a part-time
job in applied math and computing, at one
point the US Navy wanted an evaluation of
the survivability of the US SSBN fleet
under a special scenario of global nuclear
war limited to sea. They wanted their
results in two weeks.

I worked out some applied math,
designed, wrote, and ran the software, and
delivered in the two weeks, exactly. Some
of the math was some Poisson process
encounter rate work from the B. O.
Koopman, OEG-56 Search and Screening and
some of the rest was on continuous time,
discrete state space Markov processes
subordinated to a Poisson process from

Erhan Çinlar, Introduction to Stochastic
Processes, ISBN 0-13-498089-1.

from which I'd recently had a course.

(C) For my startup, I wanted a good way to
handle user session state. So, I wrote a
session state server. Sure, Redis could
have been used for that. What I wrote was
so simple that it was less work than even
reading the Redis documentation! So, I
used de/serialization of class instances
from/to a byte array sent/received via
simple TCP/IP sockets and two instances of
a Microsoft .NET collection class. The
program is single threaded and uses the
TCP/IP (first in, first out) FIFO input
queue for synchronization. Works fine.
That was about two days.

Hmm ... If I have 10 Web servers but just
one session state server, then I won't
need user session affinity to the Web
servers. But if I have 200 Web servers
and one session state server for each 10
Web servers, then I will need user session
state affinity to each of the 20 session
state servers.

Hmm, what to do? Ah, to each user HTTP
GET request, in my HTTP POST response am
sending an encrypted GUID value and get
GUID value back as the key in the session
state server. So, ..., maybe I should
bury in the GUID an ID of the relevant
session state server. Then let each of
the 200 Web servers go for each user to
the session state server being used for
the session for that user. Then for load
leveling of the 20 session state servers,
if usage data shows that that is
worthwhile, then once a minute or so
broadcast new assignments of session state
servers to the Web servers?

(D) There was a sudden change in some
banking laws, and a guy found a valuable
optimization problem. He used simulated
annealing, ran for days, and quit when
tired maybe without a feasible solution or
maybe with one but with no idea how close
it was to optimality.

I got involved. The first problem was 0-1
integer linear programming with 40,000
constraints and 600,000 variables. I did
some Lagrangian relaxation derivations,
wrote some Fortran code, called the IBM
Optimization Subroutine Library (OSL), and
in less than an hour on a 90 MHz PC got a
feasible solution guaranteed to be within
0.025% of optimality, all in two weeks.

But I can't always do things quickly:

To learn Microsoft's .NET, I started with

Jim Buyens, Web Database Development,
Step by Step: .NET Edition, ISBN
0-7356-1637-X.

which is beautifully done technical
writing.

Then for the rest I went to Microsoft's
MSDN and started finding, downloading,
reading, abstracting, and indexing Web
pages. It took a while, longer than an
hour, week, or month, but I got about 5000
such from MSDN and about 1000 more from
elsewhere.

That was about enough for my use of the
.NET Framework, Visual Basic .NET (not the
old Visual Basic 6.0 but close to
equivalent to C# but with a different
favor of syntactic sugar), ASP.NET for
writing Web pages, and ADO.NET for
communicating with SQL Server.

That was an "obstacle".

Sorry, Paul, such "obstacles" are just
part of the work.

For my startup, all the work uniquely mine
has been fast, fun, and easy. I saw the
problem, thought of a very different, new
solution with new data and some original
applied math for getting the results for
the users from the new data, and designed
and wrote the code. The code is several
programs communicating over TCP/IP with
24,000 statements in Visual Basic .NET in
100,000 lines of typing (lots of
documentation with the code). It all runs
as designed and appears ready for
production. The code does not need
refactoring, and there was no prototype
code or "minimum viable product" code.

And, yes, the problem is one with no good
solution but which essentially every user
of the Internet in the world would like a
solution on average a few times a week.
So to a user, my solution is just a Web
site. The monetization is via ads. So,
sure, if people like my work, my little
effort will be worth many times the $10
billion in the OP.

Summary

So, sometimes things are fast; and
sometimes there are unavoidable obstacles.